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 at 
> http://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.

Reply via email to