[sqlalchemy] Re: XX and YY are both of the same direction symbol 'ONETOMANY error

2009-04-09 Thread Adrian

I have exactly the same problem with 0.5.3. On one machine the mapping
works fine with 0.5.2 on another with 0.5.3 I get the error you
mentioned.

On Apr 2, 3:36 pm, Andreas Jung li...@zopyx.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 I am getting the following error after upgrading from post-0.5.2 version
 (SVN) to 0.5.3:

 ==
 ERROR: testToolLookupVisitedBy (tool.tests.test_tool_lookup.TestToolLookup)
 - --
 Traceback (most recent call last):
   File /HRS2/local/lib/python2.4/unittest.py, line 260, in run
     testMethod()
   File
 /local/HRS2/Devel/junga/tb-dev/parts/modules-svn/toolbox/tool/tests/test_tool_lookup.py,
 line 47, in testToolLookupVisitedBy
     rows = TL.toolsVisitedBy('ajung')
   File
 /local/HRS2/Devel/junga/tb-dev/parts/modules-svn/toolbox/tool/__init__.py,
 line 70, in toolsVisitedBy
     visited_tools = session.query(VT).filter_by(benutzer=username.lower())
   File
 /local/HRS2/Devel/junga/tb-dev/eggs/SQLAlchemy-0.5.3-py2.4.egg/sqlalchemy/orm/session.py,
 line 895, in query
     return self._query_cls(entities, self, **kwargs)
   File
 /local/HRS2/Devel/junga/tb-dev/eggs/SQLAlchemy-0.5.3-py2.4.egg/sqlalchemy/orm/query.py,
 line 91, in __init__
     self._set_entities(entities)
   File
 /local/HRS2/Devel/junga/tb-dev/eggs/SQLAlchemy-0.5.3-py2.4.egg/sqlalchemy/orm/query.py,
 line 100, in _set_entities
     self.__setup_aliasizers(self._entities)
   File
 /local/HRS2/Devel/junga/tb-dev/eggs/SQLAlchemy-0.5.3-py2.4.egg/sqlalchemy/orm/query.py,
 line 114, in __setup_aliasizers
     mapper, selectable, is_aliased_class = _entity_info(entity)
   File
 /local/HRS2/Devel/junga/tb-dev/eggs/SQLAlchemy-0.5.3-py2.4.egg/sqlalchemy/orm/util.py,
 line 492, in _entity_info
     mapper = class_mapper(entity, compile)
   File
 /local/HRS2/Devel/junga/tb-dev/eggs/SQLAlchemy-0.5.3-py2.4.egg/sqlalchemy/orm/util.py,
 line 567, in class_mapper
     mapper = mapper.compile()
   File
 /local/HRS2/Devel/junga/tb-dev/eggs/SQLAlchemy-0.5.3-py2.4.egg/sqlalchemy/orm/mapper.py,
 line 653, in compile
     raise sa_exc.InvalidRequestError(One or more mappers failed to
 compile.  Exception was probably 
 InvalidRequestError: One or more mappers failed to compile.  Exception
 was probably suppressed within a hasattr() call. Message was: One or
 more mappers failed to compile.  Exception was probably suppressed
 within a hasattr() call. Message was: One or more mappers failed to
 compile.  Exception was probably suppressed within a hasattr() call.
 Message was: One or more mappers failed to compile.  Exception was
 probably suppressed within a hasattr() call. Message was:
 Hierarchies.subscribed_by and back-reference Hierarchies.subscriber are
 both of the same direction symbol 'ONETOMANY.  Did you mean to set
 remote_side on the many-to-one side ?

 The related code is:

     class Hierarchies(Base, AsDictMixin):
         __tablename__ = 'hierarchies'
         __table_args__ = ( { 'autoload' : True, })
         __mapper_args__ = ({'extension' : HierachiesDeletionLogger()})

         id = Column(Integer, Sequence('hierarchies_seq'), primary_key=True)
         parent_id = Column(Integer, ForeignKey('hierarchies.id'))
         hierarchyshare_id = Column(Integer, ForeignKey('hierarchies.id'))
         pos = Column(Integer)

     Hierarchies.subscribed_by = relation('Hierarchies',

 primaryjoin=Hierarchies.hierarchyshare_id==Hierarchies.id,
                                  backref=backref(subscriber,
 remote_side=Hierarchies.hierarchyshare_id),
                                  remote_side=Hierarchies.hierarchyshare_id,
                                  uselist=True,
                                  )

 Anything I am missing or something that changed over the last two weeks
 at this point?

 Andreas

 - --
 ZOPYX Ltd.  Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
 Web:www.zopyx.com- Email: i...@zopyx.com - Phone +49 - 7071 - 793376
 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK
 - 
 E-Publishing, Python, Zope  Plone development, Consulting

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (Darwin)
 Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/

 iEYEARECAAYFAknUzXIACgkQCJIWIbr9KYwdZgCfVfo9ZN2bNPM4iaxZoFXdcuuE
 yPoAoMaqN2Wr219oL+kviY7dtotIqh/M
 =RG8E
 -END PGP SIGNATURE-

  lists.vcf
  1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en

[sqlalchemy] Re: XX and YY are both of the same direction symbol 'ONETOMANY error

2009-04-09 Thread Michael Bayer



On Apr 2, 10:36 am, Andreas Jung li...@zopyx.com wrote:
 The related code is:

     class Hierarchies(Base, AsDictMixin):
         __tablename__ = 'hierarchies'
         __table_args__ = ( { 'autoload' : True, })
         __mapper_args__ = ({'extension' : HierachiesDeletionLogger()})

         id = Column(Integer, Sequence('hierarchies_seq'), primary_key=True)
         parent_id = Column(Integer, ForeignKey('hierarchies.id'))
         hierarchyshare_id = Column(Integer, ForeignKey('hierarchies.id'))
         pos = Column(Integer)

     Hierarchies.subscribed_by = relation('Hierarchies',

 primaryjoin=Hierarchies.hierarchyshare_id==Hierarchies.id,
                                  backref=backref(subscriber,
 remote_side=Hierarchies.hierarchyshare_id),
                                  remote_side=Hierarchies.hierarchyshare_id,
                                  uselist=True,
                                  )

yes, you have the same remote_side on both the forwards and the
backwards reference, indicating they are both one-to-many from
hierarchies.id to hiearchies.parent_id.   The remote_side in the many-
to-one backref should point to Hierarchies.id.



 Anything I am missing or something that changed over the last two weeks
 at this point?

 Andreas

 - --
 ZOPYX Ltd.  Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
 Web:www.zopyx.com- Email: i...@zopyx.com - Phone +49 - 7071 - 793376
 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK
 - 
 E-Publishing, Python, Zope  Plone development, Consulting

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (Darwin)
 Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/

 iEYEARECAAYFAknUzXIACgkQCJIWIbr9KYwdZgCfVfo9ZN2bNPM4iaxZoFXdcuuE
 yPoAoMaqN2Wr219oL+kviY7dtotIqh/M
 =RG8E
 -END PGP SIGNATURE-

  lists.vcf
  1KViewDownload
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: XX and YY are both of the same direction symbol 'ONETOMANY error

2009-04-09 Thread Michael Bayer

Adrian wrote:

 in my case it must be something different. The following code works
 perfectly fine in 0.5.2:

 mapper(Contact, CONTACTS)

 mapper(Atom, ATOMS,
 properties = {
 'Contacts': relation(Contact,
 primaryjoin = Contact.atom_id==ATOMS.c.id,
 foreign_keys = [Contact.atom_id], lazy=True,
 uselist=True, viewonly=True,
 backref = backref('Atom', primaryjoin =
 Contact.atom_id==ATOMS.c.id,
 foreign_keys =
 [ATOMS.c.id],
 lazy=True, uselist=False,
 viewonly=True)
 )
 })

 In: atom = session.query(Atom).filter(Atom.id==57).one()

 In: atom.Contacts
 Out: [Contact(57, 9)]

 In 0.5.3 however, the backref() will throw the following error:

 ArgumentError: Atom.Contacts and back-reference Contact.Atom are both
 of the same direction symbol 'ONETOMANY.  Did you mean to set
 remote_side on the many-to-one side ?

 Any ideas?

in this case you have set the foreign_keys collection backwards on the
backref.  the foreign key is always contact.atom_id.  its also not needed
if you have ForeignKey objects on your table metadata.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---