On Aug 4, 2007, at 7:43 AM, Alexandre CONRAD wrote:
> > Alexandre CONRAD wrote: > >> Ok, maybe I got influenced by articles about nested sets beeing >> better, >> as pointed Mike. Now I got you guys advices, I'll look deeper into >> adjacency list. I'm glad I've had such feedback on my problem. This >> defenitly helps, even more when you just don't know from where to >> start. >> >> Also these "optimized_al.py" and "adjacency_list.py" examples will >> help >> me building my own SA models for this part of my project. > > All these hierarchical possiblities are a lot of information at the > same > time for me. Althought, I seem to be realizing that I will have > another > issue: I need to keep track of the playlist's nodes ordering. And it > seems that the adjacency list method doesn't allow me to keep track of > the ordering. Is this correct ? no, youre free to order by whatever crierion youd like. the examples return the nodes in insert order and will duplicate the input document. > > For now, we have mostly talked about vertical, top/down navigation > style. From the XML DOM specs, this would correspond to the > "parentNode" > (single node), "childNodes" (list of nodes) of the "Node" object. But > how about horizontal navigation? Having a childNodes() method to my > Node > class would return an unorder list of nodes (or ordered by id, > which has > no logic with the playlist of course). you can order by whatever you like. the example is ordering in the identical order as the source document but this can be changed. > > XML DOM refers to methods like "previousSibling", "nextSibling", > "firstChild", "lastChild", "insertBefore". elementtree supports these paradigms, just check out the docs: http://effbot.org/zone/element-index.htm > > From my XML example, I wouldn't want to have "outro.avi" read before > "intro.avi", this is primordial: > > <main> > <video>intro.avi</video> > ... > <video>outro.avi</video> > </main> er, records are inserted in the order they're read from the source XML. > Somehow, I need to have a field that keeps an ordering number for the > nodes. Meaning that every create/move/delete action would still > need me > to update the ordering number of other nodes, like the Nested Set > model > does. the example works from a notion of re-storing an XML document by deleting all preexisting nodes completely, and re-inserting new nodes. mutation operations occur on the ElementTree structure first, then when persisted they and their ordering are faithfully duplicated into the database. this is consistent with the idea that we are using a "serialization" paradigm here where an object of one type is encoded into a new format...new persists occur en-masse, not based on partial manipulations. if you wanted to support direct mutation operations on Node objects without mass deletes/inserts, add an "orderby" column to the nodes table and use a recipe like OrderingList: http://www.sqlalchemy.org/ docs/plugins.html#plugins_orderinglist hope this helps... --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
