Skip to content

Export to nwb #7

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

Merged
merged 54 commits into from
Mar 14, 2022
Merged

Export to nwb #7

merged 54 commits into from
Mar 14, 2022

Conversation

bendichter
Copy link
Contributor

No description provided.

bendichter and others added 2 commits December 16, 2021 11:51
Co-authored-by: Dimitri Yatsenko <dimitri@datajoint.com>
Co-authored-by: Dimitri Yatsenko <dimitri@datajoint.com>
@CBroz1
Copy link
Contributor

CBroz1 commented Dec 16, 2021

The gh action buildtest is failing because there was a change to usernames. If you swap dja for anaconda in the dockerfile, as shown here, it should fix the issue.

@bendichter
Copy link
Contributor Author

@CBroz1 why add a SessionNote table? Wouldn't it be better to just add this as a field of the Session table?

@CBroz1
Copy link
Contributor

CBroz1 commented Dec 17, 2021

@CBroz1 why add a SessionNote table? Wouldn't it be better to just add this as a field of the Session table?

Arguably, SessionDirectory and SessionNote could both be folded into as nullable foreign keys. The thought process here is that not all users will use either, but the central Session table has a lot of downstream connections, so better to keep it as clean as possible. E.g - many use cases will say session_key = (session.Session & 'subject="target"').fetch1("KEY") - We might save some hassle if someone forgets the fetch("KEY") method by only including primary keys.

Thinking it through, maybe SessionDirectory and SessionNote should be part tables of Session?

@bendichter
Copy link
Contributor Author

@CBroz1 I don't see what you are gaining by making either session_note or session_directory their own tables. It complicates the schema and necessitates more complex queries. I generally think of tables as handling 1-many and many-many relationships. If you have a 1-1 relationship, such as session to session_note, IMO it is better to make a fatter table with nullable fields than add additional tables. These fields would not be keys, so it should not affect any other tables that link to Session.

Co-authored-by: Dimitri Yatsenko <dimitri@datajoint.com>
bendichter and others added 2 commits December 17, 2021 14:54
Co-authored-by: Dimitri Yatsenko <dimitri@datajoint.com>
Co-authored-by: Dimitri Yatsenko <dimitri@datajoint.com>
@CBroz1
Copy link
Contributor

CBroz1 commented Dec 17, 2021

@CBroz1 I don't see what you are gaining by making either session_note or session_directory their own tables.

Caught up with other folks on this. The separation of tables here is based on the expected timing of data entry or need to update.

  1. Users may wish to add notes about the session after processing steps.
  2. Session/Subject data entry may occur separately from file management, and file organization may change mid-project.

This way, we permit later entry, and avoid cascading deletes or updates to this session.Session table with many downstream connections.

@CBroz1 CBroz1 mentioned this pull request Dec 28, 2021
Co-authored-by: Chris Brozdowski <CBrozdowski@yahoo.com>
bendichter and others added 3 commits December 29, 2021 07:42
Co-authored-by: Dimitri Yatsenko <dimitri@datajoint.com>
Co-authored-by: Dimitri Yatsenko <dimitri@datajoint.com>
Copy link
Contributor

@CBroz1 CBroz1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks good here. The only piece I would change would be to move the integration test to the test folder of workflow-session. This could be done pretty easily via PR to the CBroz1:nwb branch which has an open PR we plan to close out this week.

# Conflicts:
#	element_session/export/nwb.py
#	element_session/session_with_id.py
#	requirements.txt
Copy link
Collaborator

@kabilar kabilar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bendichter! Great work. A few minor documentation suggestions above.

@kabilar kabilar self-assigned this Mar 13, 2022
bendichter and others added 8 commits March 14, 2022 09:09
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
Co-authored-by: Kabilar Gunalan <kabilar@datajoint.com>
@bendichter
Copy link
Contributor Author

@kabilar all look good. I do not have merge privileges so feel free to merge when you are ready.

Copy link
Collaborator

@kabilar kabilar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @bendichter!

@kabilar kabilar merged commit 735977d into datajoint:main Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants