Thanks Michael,
this solved most of my doubts.
Greetings
neurino
On Nov 16, 5:51 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> On Nov 16, 2010, at 4:19 AM, neurino wrote:
>
>
>
>
>
> > I didn't mean mapping Root to a Table (if not necessary) is my intent,
> > what I'd like to know is how to get the same behavior without the
> > bloat of an extra table.
>
> >> make your application work a certain way (where "certain way" here is not
> >> clear)
>
> > I make an example, maybe I'm wrong tho:
>
> > let's say I delete an item, I'd expect not to find this item anymore
> > in its (ex) parent items
>
> >>>> subarea.items
> > [<item>]
> >>>> session.delete(subarea.items[0])
> >>>> session.commit()
> >>>> subarea.items
> > []
>
> > This would be not the same for root's areas if I just use a query
>
> >>>> root.areas = query(Area).all()
> >>>> root.areas
> > [<area>]
> >>>> session.delete(root.areas[0])
> >>>> session.commit()
> >>>> root.items
> > [<area>]
>
> > I hope I has been able to focus on my question now.
>
> right so I'd just make the attribute "live":
>
> Session = scoped_session(sessionmaker())
>
> class Root(object):
> �...@property
> def areas(self):
> return Session.query(Area).all()
>
> singleton_root = Root()
>
> class Area(object):
> parent = singleton_root
>
> This is no different than the example above -
> Session.delete(someobject.collection[someindex]) does not remove the item
> from the collection - its only because of the call to commit() that
> someobject.collection is expired, and is then reloaded.
>
> If you'd like to later add caching to Root.areas such that the collection is
> pulled from memory until Session.commit() is called, you could enhance
> Root.areas to maintain values in a cache, such as a WeakKeyDictionary which
> uses Session().transaction as the key.
>
>
>
>
>
> > Thanks for your help
> > neurino
>
> > On Nov 15, 9:57 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> >> On Nov 15, 2010, at 10:46 AM, neurino wrote:
>
> >>> Thanks for your answer first.
>
> >>> Root is a singleton, its class is not mapped to a table.
>
> >>> What I mean is I could add a table "roots" to the database with a
> >>> sigle row and add areas a foreign key "root_id" and create a
> >>> relationship as from subareas with parent area and get what I'm
> >>> talking about.
>
> >> sure, then you're mapping Root to a table, and having just one row. That
> >> would make Root.area act exactly like a relationship() though its a little
> >> strange to have a row in the database just to make your application work a
> >> certain way (where "certain way" here is not clear).
>
> >>> This relationship, between root and area, as long as areas and
> >>> subareas would come in handy for example to traverse the tree for
> >>> extracting an xml simply, or to make recursive calculations.
>
> >>> Before sqlalchemy I was used to add all areas, subareas, items, parent
> >>> attributes to classes by myself but now I'm in the situation that 80%
> >>> of the work is done by sqlalchemy automatically and I'm not sure how
> >>> to fill the remaining, possibly having both areas and subareas behave
> >>> at the same way to avoid confusion (just as an example, lazy loading).
>
> >>> Thanks for your support
> >>> neurino
>
> >>> On Nov 15, 3:49 pm, Michael Bayer <mike...@zzzcomputing.com> wrote:
> >>>> On Nov 15, 2010, at 8:06 AM, neurino wrote:
>
> >>>>> So no advice?
>
> >>>>> Are relationships and backref something more than attributes I can
> >>>>> setup with a query?
>
> >>>>> Thank you for your support.
>
> >>>> what's not stated clearly here is what "Root" is. If that's not a class
> >>>> mapped to a table, then you'd just need to use regular Python attributes
> >>>> and descriptors to establish the in-python behavior you're looking for.
> >>>> Seems like its essentially some kind of query object, so your
> >>>> query.all()/.parent = some_root approach is what you'd go with, though
> >>>> it would appear that Root is a singleton anyway, meaning this could be
> >>>> established on Area at the class level instead of assigning to each
> >>>> instance.
>
> >>>> Its not clear what other behavior of "relationship()" would apply here,
> >>>> since Root has no database identity.
>
> >>>>> On Nov 11, 9:45 am, neurino <neur...@gmail.com> wrote:
> >>>>>> I have a tree structure
>
> >>>>>> Root
> >>>>>> |
> >>>>>> +--Area
> >>>>>> | |
> >>>>>> | +--SubArea
> >>>>>> | | |
> >>>>>> | | +--Item
> >>>>>> | | |
> >>>>>> | | +--Item
> >>>>>> | |
> >>>>>> | +--SubArea
> >>>>>> | |
> >>>>>> | +--Item
> >>>>>> | |
> >>>>>> | +--Item
> >>>>>> |
> >>>>>> +--Area
> >>>>>> |
> >>>>>> +--SubArea
> >>>>>> | |
> >>>>>> | +--Item
> >>>>>> | |
> >>>>>> | +--Item
> >>>>>> |
> >>>>>> +--SubArea
> >>>>>> |
> >>>>>> +--Item
> >>>>>> |
> >>>>>> +--Item
>
> >>>>>> The tree structure corresponds to slqalchemy db tables `areas`,
> >>>>>> `subareas` and `items`.
>
> >>>>>> Something like this:
>
> >>>>>> mapper(Area, areas_table, properties={
> >>>>>> 'subareas': relationship(SubArea, backref='parent'),
> >>>>>> })
> >>>>>> mapper(SubArea, subareas__table, properties={
> >>>>>> 'items': relationship(Item, backref='parent'),
> >>>>>> })
> >>>>>> mapper(Item, items_table)
>
> >>>>>> so each Area instance will have a `subareas` list and each SubArea
> >>>>>> will have a `items` list,
>
> >>>>>> also I easyly get a backref `parent` from Item to parent SubArea and
> >>>>>> from
> >>>>>> SubArea to parent Area.
>
> >>>>>> But this won't be for Root: it will not have a `areas` list in Root
> >>>>>> nor its areas will have a parent reference to Root.
>
> >>>>>> The quick-and-dirty solution is to do this in Root:
>
> >>>>>> self.areas = query(Area).all()
> >>>>>> for area in self.areas:
> >>>>>> area.parent = self
>
> >>>>>> But it won't be the same thing as sqlalchemy `relationship` attributes
> >>>>>> so:
> >>>>>> are there alternative solutions more sqlalchemy-like?
>
> >>>>>> Any tip appreciated!
>
> >>>>>> Thank you for your support
>
> >>>>>> Greetings
> >>>>>> neurino
>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "sqlalchemy" group.
> >>>>> To post to this group, send email to sqlalch...@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> sqlalchemy+unsubscr...@googlegroups.com.
> >>>>> For more options, visit this group
> >>>>> athttp://groups.google.com/group/sqlalchemy?hl=en.
>
> >>> --
> >>> You received this message because you are subscribed to the Google Groups
> >>> "sqlalchemy" group.
> >>> To post to this group, send email to sqlalch...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> sqlalchemy+unsubscr...@googlegroups.com.
> >>> For more options, visit this group
> >>> athttp://groups.google.com/group/sqlalchemy?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sqlalchemy" group.
> > To post to this group, send email to sqlalch...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > sqlalchemy+unsubscr...@googlegroups.com.
> > For more options, visit this group
> > athttp://groups.google.com/group/sqlalchemy?hl=en.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to sqlalch...@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.
