I agree with you. > > purchases=(db.user.id==db.order.user)&(db.item.id==db.order.item) > > rows=db(purchases).select(db.user.ALL,db.item.ALL,db.order.amount) > > However, this I cannot parse clearly in my head. But that's certainly > because I do not actively work with DAL.
Anther way the DAL differs from SQLAlchemy is that the former has very few keywords. We try to do as much as possible with operators. With some exceptions all web2py queries have the following syntax db([where clause]) defines a set db([where clause]).select([what you what to select], [how you want to select them]) The code above (db(purchases)....) generates SELECT user.id, user.lname, user.fname, item.label, order.amout from user, item, order WHERE user.id=order.user AND item.id=oder.item; Here are some more examples: http://www.web2py.com/examples/default/dal Massimo On Apr 27, 11:12 am, Michel Albert <[email protected]> wrote: > On Apr 27, 4:04 pm, mdipierro <[email protected]> wrote: > > > > User( [user_id], fname, lname, ... ) > > > Item( [item_id], label ) > > > ItemOrder( [user_id, item_id], amount ) > > > This shows a many-to-many relationship (ItemOrder) with an attached > > > attribute (amount). Modeling this in SQLAlchemy was very easy. And > > > it's a very common situation. How well web2py handles this, I cannot > > > say. > > > db.define_table('user',SQLField('fname'),SQLField('lname)) > > db.define_table('item',SQLField('label')) > > db.define_table('order',SQLField('user',db.user),SQLField > > ('item',db.item),SQLField('amount','double')) > > This does indeed look very simple and straightforward :) I can grok > this without reading the docs even :) > > > purchases=(db.user.id==db.order.user)&(db.item.id==db.order.item) > > rows=db(purchases).select(db.user.ALL,db.item.ALL,db.order.amount) > > However, this I cannot parse clearly in my head. But that's certainly > because I do not actively work with DAL. > > > I'd argue that we do not need as much documentation for the DAL as > > SQLAlchemy because it more intuitive. But this is a personal opinion. > > I would say "yes". Everyone has different ways of looking at problems. > What might seem intuitive to you might not be so for someone else. > This is a very common problem when designing user interfaces. And in a > certain way, an ORM is a textual user interface to the underlying > database. Last week I had a 30min discussion (no, seriously) about the > text and icon of a button which changes between two totally different > states (which means it was *not* an on/off button). Space was limited, > so writing too much text was out of the question, so we discussed > about which image to use. Eventually I decided, if this is already an > issue between us two developers, we needed to redesign that button > because it would surely confuse end-users. But when thinking about the > use-case, everything was totally obvious to me. Not so for my co- > worker ;) > > I believe this analogy hold very true as well for any library. You > might think it intuitive, others might think not. And to those people, > an extensive doc would help to clarify things. But, from what I've > seen so far, DAL looks mostly intuitive to me as well. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
