Skip to content

Drop all parts when master is dropped in a master-part relationship. #374

@dimitri-yatsenko

Description

@dimitri-yatsenko

This is a rare problem but it can occur.

If a part table does not reference its master, then dropping the master will result in part tables with no master. DataJoint does not know how to handle this situation and throws an error like this:

---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
~/dev/datajoint-python/datajoint/schema.py in spawn_missing_classes(self)
    124             try:
--> 125                 master_class = self.context[to_camel_case(groups['master'])]
    126             except KeyError:

KeyError: 'Response'

During handling of the above exception, another exception occurred:

DataJointError                            Traceback (most recent call last)
<ipython-input-4-fffe84c8c428> in <module>()
      1 from pipeline import experiment, reso, meso, shared
----> 2 from stimline import stimulus, tune

~/dev/stimuli/python/stimline/tune.py in <module>()
    122 
    123 @schema
--> 124 class Response(dj.Computed):
    125     definition = """  # response to directional stimulus
    126     -> Activity

~/dev/stimuli/python/stimline/tune.py in Response()
    185 
    186 
--> 187     schema.spawn_missing_classes()

~/dev/datajoint-python/datajoint/schema.py in spawn_missing_classes(self)
    125                 master_class = self.context[to_camel_case(groups['master'])]
    126             except KeyError:
--> 127                 raise DataJointError('The table %s does not follow DataJoint naming conventions' % table_name)
    128             part_class = type(class_name, (Part,), dict(definition=...))
    129             part_class._master = master_class

DataJointError: The table __response__meso_trial does not follow DataJoint naming conventions

Although it's unusual to create part tables that don't reference their masters, it is possible and this needs to be fixed.

I propose the following fix: Dropping a master table should result in dropping of all its parts regardless of whether they make a foreign key reference to the master or not.

Metadata

Metadata

Labels

enhancementIndicates new improvementsstaleIndicates issues, pull requests, or discussions are inactive

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions