[sqlalchemy] Re: Many-to-Many Adjacency Relationships
Ok,
I get it working. See below.
On Dec 7, 2007 4:09 PM, Bert Wesarg [EMAIL PROTECTED] wrote:
Hello all,
I need a little help, guidance to get a Many-to-Many Adjacency
Relationships, a.k.a. a dependency graph working.
Here is the short code:
metadata = MetaData('sqlite:///')
tasks_table = Table('tasks', metadata,
Column('id', Integer, primary_key = True),
Column('name', String()),
)
task_depends_on_tasks_table = Table('task_depends_on_tasks', metadata,
Column('task_id', Integer, ForeignKey('tasks.id')),
Column('dependent_id', Integer, ForeignKey('tasks.id')),
)
metadata.create_all()
class Task(object):
def __init__(self, name):
self.name = name
The problem is off cause the mapping configuration, some blindly
copy'n'pasting ended up in this:
m = mapper(Task, tasks_table,
properties = {
'dependsOn' : relation(Task,
secondary = task_depends_on_tasks_table,
remote_side = [tasks_table.c.id],
remote_side = [task_depends_on_tasks_table.c.dependent_id],
Bert
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Determining types of joined attributes
hmm strange, i tried this out with sqlalchemy version 0.4.1 but it does not seem to work... s.name u'HALN01100601' isinstance(s.name, sqlalchemy.orm.PropertyLoader) False s.targets [tcd_sample_database.model.samples.Target object at 0xb608dcac] isinstance(s.targets, sqlalchemy.orm.PropertyLoader) False both attributes were loaded by sqlalchemy. also, getattr(s.materials, direction) Traceback (most recent call last): File console, line 1, in ? AttributeError: 'InstrumentedList' object has no attribute 'direction' is this implemented in sqlalchemy 5? brendan On Dec 3, 2007 9:30 PM, Michael Bayer [EMAIL PROTECTED] wrote: id look at prop = MyClass.someattribute.property, use isinstance(prop, PropertyLoader) to determine a relation and not a scalar, combined with getattr(prop, direction) == sqlalchemy.orm.sync.MANYTOMANY, ONETOMANY, etc. to get the type of join. On Dec 3, 2007, at 3:43 PM, Brendan Arnold wrote: hi there, i'd like a way to determine if an attribute of an orm object is: a:) a sqlalchemy generated list of objects (i.e. many-to-many) b:) a single sqlalchemy joined object (i.e.one-to-many) c:) a 'scalar' loaded from the database (i.e. a string, float, integer) at present i'm copying the text generated by 'type(orm_obj.joined_list)' to determine a: and a 'type(float, int etc.)' for c:, whats left is b. this seems shakey, is there a better way? are there some 'types' defined in sqlalchemy? brendan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Missing sqlalchemy.engine.RowProxy.__ne__
Hi. I suggest that the attached patch be applied to trunk. I was working on a small database-comparison tool which used != between two RowProxy objects, and it took me a little while to realize that it was not behaving equivalently to == negated. -- Knut Aksel Røysland --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- Property changes on: lib/sqlalchemy/sql ___ Name: svn:ignore + *.pyc Index: lib/sqlalchemy/engine/base.py === --- lib/sqlalchemy/engine/base.py (revision 3887) +++ lib/sqlalchemy/engine/base.py (working copy) @@ -1244,6 +1244,9 @@ (other == tuple([self.__parent._get_col(self.__row, key) for key in xrange(len(self.__row))]))) +def __ne__(self, other): +return not self.__eq__(other) + def __repr__(self): return repr(tuple(self))
[sqlalchemy] Re: Determining types of joined attributes
On Dec 8, 2007, at 2:09 PM, Brendan Arnold wrote:
hmm strange, i tried this out with sqlalchemy version 0.4.1 but it
does not seem to work...
s.name
u'HALN01100601'
isinstance(s.name, sqlalchemy.orm.PropertyLoader)
False
s.targets
[tcd_sample_database.model.samples.Target object at 0xb608dcac]
isinstance(s.targets, sqlalchemy.orm.PropertyLoader)
False
both attributes were loaded by sqlalchemy. also,
getattr(s.materials, direction)
Traceback (most recent call last):
File console, line 1, in ?
AttributeError: 'InstrumentedList' object has no attribute 'direction'
here is a code example illustrating my previous email:
from sqlalchemy import *
from sqlalchemy.orm import *
from sqlalchemy.orm.properties import PropertyLoader
from sqlalchemy.orm.sync import ONETOMANY, MANYTOONE, MANYTOMANY
metadata = MetaData()
t = Table('foo', metadata, Column('id', Integer, primary_key=True))
t2 = Table('bar', metadata, Column('id', Integer, primary_key=True),
Column('fooid', Integer, ForeignKey('foo.id')))
class T(object):pass
class T2(object):pass
mapper(T, t, properties={
't2s':relation(T2)
})
mapper(T2, t2)
prop = T.t2s.property
if isinstance(prop, PropertyLoader):
if prop.direction == ONETOMANY:
print onetomany
elif prop.direction == MANYTOONE:
# etc
brendan
On Dec 3, 2007 9:30 PM, Michael Bayer [EMAIL PROTECTED]
wrote:
id look at prop = MyClass.someattribute.property, use
isinstance(prop,
PropertyLoader) to determine a relation and not a scalar, combined
with getattr(prop, direction) == sqlalchemy.orm.sync.MANYTOMANY,
ONETOMANY, etc. to get the type of join.
On Dec 3, 2007, at 3:43 PM, Brendan Arnold wrote:
hi there,
i'd like a way to determine if an attribute of an orm object is:
a:) a sqlalchemy generated list of objects (i.e. many-to-many)
b:) a single sqlalchemy joined object (i.e.one-to-many)
c:) a 'scalar' loaded from the database (i.e. a string, float,
integer)
at present i'm copying the text generated by
'type(orm_obj.joined_list)' to determine a: and a 'type(float, int
etc.)' for c:, whats left is b.
this seems shakey, is there a better way? are there some 'types'
defined in sqlalchemy?
brendan
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Elixir 0.5.0 released!
I am very pleased to announce that version 0.5.0 of Elixir (http://elixir.ematia.de) is now available. As always, feedback is very welcome, preferably on Elixir mailing list. This is mostly a bug fixes release, but we have also had some pretty important changes to the default values for options. Please look at http://elixir.ematia.de/trac/wiki/Migrate04to05 for detailed upgrade notes. The full list of changes can be seen at: http://elixir.ematia.de/trac/browser/elixir/tags/0.5.0/CHANGES What is Elixir? - Elixir is a declarative layer on top of the SQLAlchemy library. It is a fairly thin wrapper, which provides the ability to create simple Python classes that map directly to relational database tables (this pattern is often referred to as the Active Record design pattern), providing many of the benefits of traditional databases without losing the convenience of Python objects. Elixir is intended to replace the ActiveMapper SQLAlchemy extension, and the TurboEntity project but does not intend to replace SQLAlchemy's core features, and instead focuses on providing a simpler syntax for defining model objects when you do not need the full expressiveness of SQLAlchemy's manual mapper definitions. Mailing list http://groups.google.com/group/sqlelixir/about -- Gaëtan de Menten http://openhex.org --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Undeferring attributes off joined entities
t1, t2 = Table1.options(undefer(table2.large_col)).join(table2).add_entity(Table2).first() does not load large_col (or even put it in the SQL sent) on t2. Is undefer meant for eager loading in this scenario only, or have I stumbled upon a bug? (if the former, is there a way to achieve what I was trying to do?) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Undeferring attributes off joined entities
On Dec 8, 2007, at 6:17 PM, Chris M wrote: t1, t2 = Table1 .options (undefer (table2.large_col)).join(table2).add_entity(Table2).first() does not load large_col (or even put it in the SQL sent) on t2. Is undefer meant for eager loading in this scenario only, or have I stumbled upon a bug? (if the former, is there a way to achieve what I was trying to do?) query options currently only apply to the main entity.in this case specfically a new syntax would need to be introduced since its not clear if the above option applies to the attribute as applied to the Table1.table2.large_col attribute or on the large_col attribute on the secondary entity (since the two collections of Table2 could be disjoint). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Undeferring attributes off joined entities
options() could work like joinpoints do - after an add_entity, options() refers to that entity. On Dec 8, 7:12 pm, Michael Bayer [EMAIL PROTECTED] wrote: On Dec 8, 2007, at 6:17 PM, Chris M wrote: t1, t2 = Table1 .options (undefer (table2.large_col)).join(table2).add_entity(Table2).first() does not load large_col (or even put it in the SQL sent) on t2. Is undefer meant for eager loading in this scenario only, or have I stumbled upon a bug? (if the former, is there a way to achieve what I was trying to do?) query options currently only apply to the main entity.in this case specfically a new syntax would need to be introduced since its not clear if the above option applies to the attribute as applied to the Table1.table2.large_col attribute or on the large_col attribute on the secondary entity (since the two collections of Table2 could be disjoint). --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: Undeferring attributes off joined entities
On Dec 8, 2007, at 7:25 PM, Chris M wrote:
options() could work like joinpoints do - after an add_entity,
options() refers to that entity.
probably. ive been hesitant to make things go off of add_entity() as
of yet.though actually this is probably not very hard to do. youd
have to add the option as undefer('large_col'), and i bet if you were
to change line 542 of interfaces.py to:
if query._entities:
mapper = query._entities[-1][0]
else:
mapper = query.mapper
it *might* work with just that change.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Undeferring attributes off joined entities
One thing I'd be worried about is that after an add_entity there is no
way to set options on the main entity afterwards. You could provide a
reset_entitypoint, but it wouldn't work the same as with joins because
after a reset_joinpoint you can rejoin along the same path to filter
more criterion if necessary. Still, I think some functionality is
better than no functionality... it's not that big of a deal, is it?
On Dec 8, 8:23 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Dec 8, 2007, at 7:25 PM, Chris M wrote:
options() could work like joinpoints do - after an add_entity,
options() refers to that entity.
probably. ive been hesitant to make things go off of add_entity() as
of yet.though actually this is probably not very hard to do. youd
have to add the option as undefer('large_col'), and i bet if you were
to change line 542 of interfaces.py to:
if query._entities:
mapper = query._entities[-1][0]
else:
mapper = query.mapper
it *might* work with just that change.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: Undeferring attributes off joined entities
On Dec 8, 2007, at 9:55 PM, Chris M wrote:
One thing I'd be worried about is that after an add_entity there is no
way to set options on the main entity afterwards. You could provide a
reset_entitypoint, but it wouldn't work the same as with joins because
after a reset_joinpoint you can rejoin along the same path to filter
more criterion if necessary. Still, I think some functionality is
better than no functionality... it's not that big of a deal, is it?
when the notion of reset_entitypoint comes in, things have just
gottten out of hand. at some point we're going to have to decide
that order is significant with query's generative behavior, and people
will have to use it with that knowledge in mind. its already been
suggested as a result of other behaviors (such as
query[5:10].order_by('foo') doesnt generate a subquery, for example).
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
