Thread: [SQLObject] Re: [TurboGears] Re: Is 'ForeignKey' broken in SQLObject?
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Kevin D. <da...@gm...> - 2005-10-26 13:09:43
|
On 10/26/05, Todd Greenwood <t.g...@gm...> wrote: > > On a related note: Is it possible to use orderBy on a secondary table? > For example: > > #this is not correct, but shows what I'd like > Page.byPagename('FrontPage').entries(orderBy=3D'revision') Ian is talking about changing how some of the join machinery works for 0.8, so this may be a possible thing to get into that version. > > #nor is this correct > Page.byPagename('FrontPage').entries.select(revision=3D1) > > #From the docs, this looks to be the correct path: > for c in Entry.select(AND(Entry.pageID =3D=3D Page.q.id, > Page.q.pagename=3D=3D'FrontPage')): > print c The trick with this is to take a look at what Class.q.* gets you. Those things are basically placeholders for query expressions and they understand the operators. If you do this: print Entry.q.id =3D=3D 10 you get: (entry.id =3D 10) which gives you an idea where you want to be. I think you want: for c in Entry.select(AND(Entry.q.id =3D=3D Page.q.id, Page.q.paegname=3D=3D'FrontPage')) but I also think there's another parameter needed to tell sqlobject that you're using the other table. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: ki...@bl... company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com |
From: Kevin D. <da...@gm...> - 2005-10-28 19:44:15
|
p1.addEntry(column1=3Dfoo, column2=3Dbar) sounds good to me. I think p1.destroySelf exists because there's a delete classmethod. Thanks for the enumeration of methods. I do think these would make a friendlier API. Kevin On 10/28/05, Todd Greenwood <t.g...@gm...> wrote: > > I'm all for clearer syntax, but let me clear up what I was suggesting. > > p1 =3D Page(...) > p1.addEntry(Entry(...)) or p1.addEntry(...) > > Not: > > p1 =3D Page(...) > e =3D Entry(***page =3D p1***) > p1.addEntry(e) > > Specifically, I'm suggesting that SQLObject introspect the added object > at this point, and make the nec primary key to foreign key mapping > automatically: > > p1.addEntry(Entry(...)) #Internally, the Entry.page is set to p1 by > SQLObject, not the programmer > > As an example of how Django does this sort of thing, here is a trimmed > down example from their web site: > > The Django usage of this would be like so: > > # Create a Reporter. > >>> r =3D reporters.Reporter(first_name=3D'John') > > <snip> > > # Create an Article via the Reporter object. > >>> new_article =3D r.add_article(headline=3D"John's second story") > > http://www.djangoproject.com/documentation/models/many_to_one/ > > Model source code > > from django.core import meta > > class Reporter(meta.Model): > first_name =3D meta.CharField(maxlength=3D30) > > class Article(meta.Model): > headline =3D meta.CharField(maxlength=3D100) > reporter =3D meta.ForeignKey(Reporter) > > API reference > Reporter objects have the following methods: > > * add_article() > * delete() > * get_article() > * get_article_count() > * get_article_list() > * save() > > Article objects have the following methods: > > * delete() > * get_reporter() > * save() > > -Todd > > -- Kevin Dangoor Author of the Zesty News RSS newsreader email: ki...@bl... company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com |
From: Ian B. <ia...@co...> - 2005-10-28 20:53:50
|
Kevin Dangoor wrote: > p1.addEntry(column1=foo, column2=bar) sounds good to me. I'm -1 on methods appearing due to other attributes, if it's at all possible to avoid it. This would be okay with me, though: class Page(SQLObject): entries = ManyToOne('Entry') p = Page(name='FrontPage') p.entries.create(log='why I did this') Another aspect is that 'add' shouldn't create things, it should just add things, as you would to a set. We already have add methods with RelatedJoin, and they don't create new objects. Just like sets.Set.add. This would be a good compliment to demonstrate: class Page(SQLObject): authors = ManyToMany('User') p = Page(name='FrontPage') p.authors.add(User.byUsername('ianb')) Though this could also have a "create()" method. I don't really like an add method for ManyToOne, though, since it mutates its argument; but for ManyToMany it doesn't. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Kevin D. <da...@gm...> - 2005-10-29 15:20:33
|
On 10/28/05, Ian Bicking <ia...@co...> wrote: > Kevin Dangoor wrote: > > p1.addEntry(column1=3Dfoo, column2=3Dbar) sounds good to me. > > I'm -1 on methods appearing due to other attributes, if it's at all > possible to avoid it. > > This would be okay with me, though: > > class Page(SQLObject): > entries =3D ManyToOne('Entry') > > p =3D Page(name=3D'FrontPage') > p.entries.create(log=3D'why I did this') > > Another aspect is that 'add' shouldn't create things, it should just add > things, as you would to a set. We already have add methods with > RelatedJoin, and they don't create new objects. Just like sets.Set.add. I like your example above as well. Doing things like that will allow for an API that is more consistent. Kevin |
From: Ian B. <ia...@co...> - 2005-10-26 15:22:09
|
Kevin Dangoor wrote: > On 10/26/05, Todd Greenwood <t.g...@gm...> wrote: > >>On a related note: Is it possible to use orderBy on a secondary table? >>For example: >> >>#this is not correct, but shows what I'd like >>Page.byPagename('FrontPage').entries(orderBy='revision') > > > Ian is talking about changing how some of the join machinery works for > 0.8, so this may be a possible thing to get into that version. I'm not sure I understand .entries... but I think you can do: Page.byPagename('Frontpage').entries.orderBy('revision') *If* entries is a SQLMultipleJoin. SQLMultipleJoin -- in spirit if not actual code -- will be the default kind of join when joins are refactored for 0.8. When using SQLMultipleJoin, aPage.entries will be 100% equivalent to Entry.selectBy(pageID=aPage.id). -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |