On Friday 14 November 2008 19:00:30 Michael Bayer wrote: > On Nov 14, 2008, at 11:22 AM, [EMAIL PROTECTED] wrote: > > isn't it going to be usable if > > klas.some2many_relation == obj > > is automaticaly rendered as > > klas.some2many_relation.contains( obj) > > ? > > unless the == in that case has some other meaning... > > we took that case out, its behavior was ambiguous and not really > correct from any relational standpoint. > > (btw whats "sometomany" ? "manytomany" not sufficient ? its hard > to parse these emails sometimes...) anytomany, i.e. either onetomany or manytomany
> > i'm using some query-building-functions over mixture of plain > > references and many2many and switching between the syntaxes > > depending on the attr is somewhat guesswork. > > In the face of ambiguity, refuse the temptation to guess. on the higher level of abstracion, it's not ambigiuos - Reference (n->1) vs bitemporal Reference (n->m). Well, last one has 2 subcases - to concrete version .contains(some_dbid) or to whole obj-history - .any( objid==someObjid) > > btw same goes for > > klas.some2many_relation.has( ... ) into .any() > > if you really have to work this way, > Class.attrname.property.direction will be any of ONETOMANY, > MANYTOONE, MANYTOMANY ah, okay, i'm using these and some other stuff (dbcook.about_relation), i was just thinking aloud seeing similar interfaces/comparisons being named differently just because of their specific type. so i have something like .is_or_contains() and .has_or_anyhas(), as equivalent to a.refB==b1 and a.refB.has( b_attr==value) (where refs can be either plain or bitemporal) the plain Collection (1->n) vs bitemporal Collection (m->n) case is already handled transparently, with interfaces being same: .has/.any. ciao svil --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
