Description
Migrated issue, originally created by Anonymous
At the moment classes which inherit Base are registered with just their classname. When multiple classes with the same name inherit Base a warning will appear:
SAWarning: The classname 'Class' is already in the registry of this declarative base, mapped to <class 'path.to.Class'>
If the class was registered including the module name, so 'path.to.Class', then it would be possible to uses classes with the same name. Of course as long as they obey the Python rules concerning namespaces.
Example:
When a relationship is defined a string name can be used. When only one class with this name is registered, this class can be used. If multiple classes have the same name, the path to the class can be defined in the string name.
Let's say we have the following relationship:
relation = relationship("Class")
If only one class with the name "Class" is registered with the declarative base, this class can be used. If multiple classes with the name "Class" are found, the path should be defined:
relation = relationship("path.to.Class")
When multiple classes with the same name are found and the relation defines only the class name, an error can be raised.
Multiple classes with the classname "Class" are in the registry of this declarative base. Please including the module name.
It would even be possible to list the classes with module names so the user can pick the right one.
Current workarounds:
- Don't use classes with the same name with the same declarative base
- Use multiple declarative bases
- Import the class you want a relation to and refer to this. (This is not always possible)
- Only define the relations after both classes have been declared. (This will still give the SAWarnings.)
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
Participants
Activity
sqlalchemy-bot commentedon Dec 1, 2011
Michael Bayer (@zzzeek) wrote:
I like this though I wonder about namespace collisions. We use eval(code) with a dict passed to locals that will look into the named registry when a key is otherwise missing. So a class that has "path.to.Class" would need to put tokens for "path" in the registry, as well as "path" would need to be either the actual "path" module, or some further namespaced object that then has "to" on it. The presence of many new names, i.e. for every base module, in the registry might produce other problems...or maybe not.
in any case the system where this happens starts at http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/ext/declarative.py#L1299, I guess we'd add a new "class _GetModule" to handle this new level of lookup.
sqlalchemy-bot commentedon Dec 1, 2011
Changes by Michael Bayer (@zzzeek):
sqlalchemy-bot commentedon Dec 1, 2011
Changes by Michael Bayer (@zzzeek):
sqlalchemy-bot commentedon Jan 22, 2012
Michael Bayer (@zzzeek) wrote:
this isn't high priority and has the potential to be destabilizing so pushing to 0.8 for now.
sqlalchemy-bot commentedon Jan 22, 2012
Changes by Michael Bayer (@zzzeek):
sqlalchemy-bot commentedon Aug 5, 2012
Michael Bayer (@zzzeek) wrote:
funny thing, how in #2526 we changed decl_class_registry to be weak referencing on the value side. So this becomes a lot more fun, in that we are severely limited what we can place in this dictionary for values. the "multiple class names" error suggests we need to store a value other than a class for a name with multiple hits.
sqlalchemy-bot commentedon Aug 5, 2012
Michael Bayer (@zzzeek) wrote:
6bd4694
sqlalchemy-bot commentedon Aug 5, 2012
Changes by Michael Bayer (@zzzeek):
sqlalchemy-bot commentedon Oct 28, 2012
Michael Bayer (@zzzeek) wrote:
partial paths now supported in 63a9d80