-
Notifications
You must be signed in to change notification settings - Fork 0
add IonChannelRecording #305
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
Conversation
This PR is good from my point of view, but I have an error that I really do not know how to solve. It looks like pyright cannot import ElectricalRecordingStimulusRead, but I really do not see why. Also I do not have this error when I run pyright locally. |
I cannot reproduce the pyright error locally either, so it's difficult to debug. |
app/db/model.py
Outdated
class IonChannelRecording(ElectricalCellRecording): | ||
__tablename__ = EntityType.ion_channel_recording.value | ||
|
||
ion_channel: Mapped[IonChannel] |
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 causes an error when running tests. Maybe you want to add ion_channel_id
, and a relationship ion_channel
?
… into ion-channel-recording
… into ion-channel-recording
Alright @GianlucaFicarelli I have merge the main branch and I have added ion_channel_id and a relationship ion_channel. |
… into ion-channel-recording
@GianlucaFicarelli could I ask for your help with the tests please? I have been trying to fix the sqlalchemy errors, but the number of errors only seem to grow |
app/db/model.py
Outdated
__mapper_args__ = {"polymorphic_identity": __tablename__} # noqa: RUF012 | ||
|
||
|
||
class IonChannelRecording(ElectricalCellRecording): |
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 wonder what is the reason for IonChannelRecording to inherit from ElectricalCellRecording, is it a special case of ElectricalCellRecording?
Alternatively, couldn't it be a separate class?
Or can IonChannelRecording and ElectricalCellRecording have conceptually a common base class?
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 have made it inherit from ElectricalCellRecording
, because it is indeed a special case of ElectricalCellRecording
.
In both the ion channel recording experiments and the 'regular' recording experiments having produced the ElectricalCellRecording
data we currently have on the platform, the pipette is applied to a cell (this is named a whole-cell patch clamp experiment).
But in the case of an ion channel recording, the cell has been designed in the laboratory to only express one single type of ion channel, so only currents from this type of ion channel are recorded.
So this is why I made IonChannelRecording
inherit from ElectricalCellRecording
. I also thought it would be easier (i.e. less code to write down) to just inherit from ElectricalCellRecording
.
Although making a common base class for the two classes would also be ok, in my opinion, if you think this structure would be simpler. The base class would simply have all (or most) of ElectricalCellRecording
fields.
I would personnally push for IonChannelrecording
inheriting from ElectricalCellRecording
if that is ok with you @GianlucaFicarelli
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.
@AurelienJaquier to continue and clarify the point, if we use this class/tables hierarchy:
entity -> scientific_artifact -> electrical_cell_recording -> ion_channel_recording
then, when retrieving the list of electrical_cell_recording, also the entries for the ion_channel_recording would be returned (because for each record in the ion_channel_recording table, there is also a record in the electrical_cell_recording table)
Wouldn't be surprising if we return also electrical_cell_recording built from partial data of ion_channel_recording?
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.
Ah I see. In that case, it would be better to have both classes separate, and inheriting from a RecordingBase class or something. We do not want the IonChannelRecordings to show up when we query the ElectricalCellRecordings
* origin/main: Validate scale and build_category in circuit filter (#352) Add admin delete endpoints for all routers (#281) root routes should not require auth, make sure tests reflect this (#351) Specify permission for service admin (#342) Add assets in ValidationResultRead schema (#348) Fix transaction_per_migration in alembic (#346)
|
||
label: Mapped[str] | ||
gene: Mapped[str] | ||
synonyms: Mapped[STRING_LIST] |
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.
Some points to decide or clarify:
- Should pref_label be made unique?
- Is there a validation possible for gene?
- For confirmation, should only the service admin be allowed to create a new entry?
- Do we have examples for label, gene, synonyms?
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.
- Yes, label (or pref_label) should be unique
- only admin service should be allowed to create a new entry
- we have the full list of label, gene, synonyms in register_recordings_and_ion_channels.zip in https://github.com/openbraininstitute/prod-build-ion-channel-model/issues/12
- We can validate by checking if the data corresponds to what we have in the file I mentioned above
* origin/main: Adds deterministic order fallback by entity id (#350)
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 be reviewed
super_table_args = getattr(super(), "__table_args__", ()) | ||
# add the index only to the same table where the Mixin is defined, not subclasses | ||
attr = getattr(cls, "description_vector", None) | ||
if isinstance(attr, MappedColumn): |
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 cannot find a cleaner way to avoid adding the index to the subclasses, feel free to suggest different options.
This might not work as expected if the mixin is applied to an abstract class, but it should work in our use cases (when the mixin is applied to an intermediate concrete class, or to a final child class).
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.
yeesh, that is a work around, fancy
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.
Looks good!
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.
LGTM; not sure if you want to squash the alembic versions, or if they need to be 3 separate ones.
I'm thinking to keep them separate because the 1st one is manual, while the other 2 are automatic (I could merge those 2, but still requires some manual copying of the operations in the correct order) |
Ok, no need. |
* origin/main: Add update endpoints for users (#347)
Added new update endpoint introduced in #347 |
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.
Nice! Thank you for adding it.
* origin/main: Add IonChannel and IonChannelRecording (#305) Add update endpoints for users (#347) Adds deterministic order fallback by entity id (#350) Validate scale and build_category in circuit filter (#352) Add admin delete endpoints for all routers (#281) root routes should not require auth, make sure tests reflect this (#351) Specify permission for service admin (#342) Add assets in ValidationResultRead schema (#348) Fix transaction_per_migration in alembic (#346) Add the ability to filter by name to IonChannelModel (#338)
solves https://github.com/openbraininstitute/prod-build-ion-channel-model/issues/11