-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature/sckan 275 #250
Feature/sckan 275 #250
Conversation
backend/composer/models.py
Outdated
@@ -229,7 +228,7 @@ class AnatomicalEntity(models.Model): | |||
"""Anatomical Entity""" | |||
|
|||
name = models.CharField(max_length=200, db_index=True) | |||
ontology_uri = models.URLField(unique=True) | |||
ontology_uri = models.URLField() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can't be unique because we can have children of anatomical entities with the same ontology uri
backend/composer/models.py
Outdated
|
||
class Region(AnatomicalEntity): | ||
... | ||
associated_layer = models.ForeignKey(Layer, on_delete=models.CASCADE, related_name='regions') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to make this a ForeignKey instead of a ManyToMany because when we create a connectivity statement with a region-layer pair we need to know exactly what is the region-layer pair and we expect that information to be under the umbrella of the anatomical entity model. In other words, if we want to add a complex origin to a connectivity statement we need to add an anatomical entity that contains information about the specific region and the specific layer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afonsobspinto I'm not sure I follow your comment.
I remember that a region can have multiple layers, how would this look like in the model you suggest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zsinnema A region can have multiple layers yes, but only a pair region layer represents an anatomical entity. For example:
Region: Segment L1
Layers: Lamina 1, Lamina 2, Lamina 3, Lamina 4, etc...
The anatomical entities that we have, as far as I understand, are:
- Segment L1 + Lamina 1
- Segment L1 + Lamina 2
- ....
One relevant point to consider too is that in the Connectivity Statement model we refer to AnatomicalEntity (not RegionLayerPair).
origins = models.ManyToManyField(AnatomicalEntity, related_name='origins_relations')
b8eae5e
to
1fbe45c
Compare
1fbe45c
to
416f255
Compare
I think it might make more sense to have anatomical entities as an abstract model and have as children:
|
backend/composer/models.py
Outdated
|
||
class Region(AnatomicalEntity): | ||
... | ||
associated_layer = models.ForeignKey(Layer, on_delete=models.CASCADE, related_name='regions') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afonsobspinto I'm not sure I follow your comment.
I remember that a region can have multiple layers, how would this look like in the model you suggest?
253d241
to
17447c2
Compare
17447c2
to
40f20b9
Compare
cb07d67
to
0ce72d8
Compare
I updated the description of the PR accordingly to the most recently changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@afonsobspinto I;ve been playing with the admin and for now I think it's not usable anymore.
Before the admin gave a clear overview of the KS and it's properties and linked data
In the new situation, for example look at the Destinations, the Admin interface is unusable.
Also the speed of the Admin interface went down dramatically.
Please have a closer look at the usability and speed.
Thanks
@zsinnema I did not had the time to try any of the speed improvement suggestions on the admin page yet. Would it be possible to merge this PR only with the usability changes so that @ddelpiano can test it? |
@afonsobspinto imo this is not mergable, see the attached video. In this video I open a (one) ConnectivityStatement in the admin using this link https://127.0.0.1:8000/admin/composer/connectivitystatement/296/change/ (I ingested the dev database) sckan.pg.queries.mp4 |
@zsinnema Do you believe this is not mergeable do to the high amount of queries? |
@afonsobspinto herewith a video with the dev db on my local machine and git branch develop. Ubuntu.2024-04-02.14-07-58.mp4 |
@ddelpiano The performance decreased is caused by the chanegs done in this PR/feature. Therefore I classify the implementation as being not mergable. I understand that the client also needs to see things/progress so the question is: how big is the is the performance decrease for the usability of the application. Up to you if you think we can merge it or not |
@zsinnema I can't replicate the behaviour of having such high amount of queries when running with this branch with the dev database: 2024-04-02.13-27-04.mp4This is what I did:
|
@afonsobspinto hmmm after I pulled again from Git the many queries disappeared... weird |
Closes https://metacell.atlassian.net/browse/SCKAN-275