Thread: [SQLObject] MultipleJoin inactive in version 0.6
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Nigel K. <nig...@or...> - 2004-11-02 10:37:02
|
Hi, The relation in MultipleJoin does not seem to work in version 0.6. The following simplified program gives the Traceback error below =======temp.py======= from sqlobject import * #conn = MySQLConnection(user='nigelk', db='music') conn = 'mysql://nigelk@localhost/music' class Artist(SQLObject): _connection = conn Name = StringCol() titles = MultipleJoin('TapeTitle') class TapeTitle(SQLObject): _connection = conn artist = ForeignKey('Artist') Title = StringCol() print Artist.get(1).titles ========temp.py======== Traceback (most recent call last): File "temp.py", line 18, in ? print Artist.get(1).titles AttributeError: 'Artist' object has no attribute 'titles' print Artist(1).titles worked under 0.5.2 I understand that we now need get although this was not obvious in the documentation Nigel King |
From: Max I. <ma...@uc...> - 2004-11-02 11:32:35
|
Nigel King wrote: > Hi, > The relation in MultipleJoin does not seem to work in version 0.6. > The following simplified program gives the Traceback error below Been there. Add joinColumn argument: > =======temp.py======= > from sqlobject import * > > #conn = MySQLConnection(user='nigelk', db='music') > conn = 'mysql://nigelk@localhost/music' > > class Artist(SQLObject): > _connection = conn > Name = StringCol() > titles = MultipleJoin('TapeTitle') titles = MultipleJoin('TapeTitle', joinColumn='tape_title_id') > class TapeTitle(SQLObject): > _connection = conn > artist = ForeignKey('Artist') > Title = StringCol() > > worked under 0.5.2 I understand that we now need get although this was > not obvious in the documentation IMO, either the docs must be updated or, better yet, SQLobject should somehow figure out that joinedColumn argument by itself. |
From: Oleg B. <ph...@ma...> - 2004-11-02 12:28:06
|
On Tue, Nov 02, 2004 at 01:25:12PM +0200, Max Ischenko wrote: > SQLobject should somehow figure out that joinedColumn argument by > itself. +1. Simple joins should be simple. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Carlos R. <car...@gm...> - 2004-11-02 12:42:30
|
On Tue, 02 Nov 2004 13:25:12 +0200, Max Ischenko <ma...@uc...> wrote: > IMO, either the docs must be updated or, better yet, SQLobject should > somehow figure out that joinedColumn argument by itself. Judging by the mailing list messages, that's at least the fourth time someone (including myself) have fallen on this trap recently. I've proposed a change to the documentation about two weeks ago. I don't if Ian noticed it, though. What I found is that this is something hard to explain in a clean and short way, exactly because SQLObject does such a great job to hide the complexity behind the relationship mechanism. We just expect it to be able to detect automatically the column name, which it can't do for the generic case. The reason only becomes clear when we think in terms of the underlying schema. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Andrew B. <and...@pu...> - 2004-11-02 12:54:21
|
On Tue, Nov 02, 2004 at 01:25:12PM +0200, Max Ischenko wrote: > Nigel King wrote: [...] > >worked under 0.5.2 I understand that we now need get although this was > >not obvious in the documentation > > IMO, either the docs must be updated or, better yet, SQLobject should > somehow figure out that joinedColumn argument by itself. This is a bug in SQLObject 0.6 that has since been fixed in SVN. This seems to come up fairly frequently on this list... perhaps a 0.6.1 release would be a good idea? -Andrew. |
From: Oleg B. <ph...@ma...> - 2004-11-02 13:29:09
|
On Tue, Nov 02, 2004 at 11:51:34PM +1100, Andrew Bennetts wrote: > This is a bug in SQLObject 0.6 that has since been fixed in SVN. > > This seems to come up fairly frequently on this list... perhaps a 0.6.1 > release would be a good idea? BTW, Ian! What is the status of Plan.html? Is it still relevant? outdated? obsolete? I am especially interested in Daniel Savard's inheritance patch. The absense of it forces me to use 0.5.3. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Nigel K. <nig...@or...> - 2004-11-02 13:46:39
|
Max, Thanks very much. Unfortunately the error doesn't go away it still doesn't seem to think that titles exists Traceback (most recent call last): File "temp.py", line 16, in ? print Artist.get(1).titles AttributeError: 'Artist' object has no attribute 'titles' print Artist.get(1).tapeTitles[0].Title works which is a little long winded joinedColumn='tape_title_id' did not work but joinedColumn='id' did work. I am not very expert in Python but this package appears to be getting more complicated rather than less complicated. Nigel King On 2 Nov 2004, at 11:25, Max Ischenko wrote: > Nigel King wrote: > >> Hi, >> The relation in MultipleJoin does not seem to work in version 0.6. >> The following simplified program gives the Traceback error below > > Been there. > > Add joinColumn argument: > >> =======temp.py======= >> from sqlobject import * >> #conn = MySQLConnection(user='nigelk', db='music') >> conn = 'mysql://nigelk@localhost/music' >> class Artist(SQLObject): >> _connection = conn >> Name = StringCol() >> titles = MultipleJoin('TapeTitle') > titles = MultipleJoin('TapeTitle', joinColumn='tape_title_id') > >> class TapeTitle(SQLObject): >> _connection = conn >> artist = ForeignKey('Artist') >> Title = StringCol() >> worked under 0.5.2 I understand that we now need get although this >> was not obvious in the documentation > > IMO, either the docs must be updated or, better yet, SQLobject should > somehow figure out that joinedColumn argument by itself. > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Max I. <ma...@uc...> - 2004-11-02 14:30:46
|
Nigel King wrote: > Max, > Thanks very much. Unfortunately the error doesn't go away it still > doesn't seem to think that titles exists > > Traceback (most recent call last): > File "temp.py", line 16, in ? > print Artist.get(1).titles > AttributeError: 'Artist' object has no attribute 'titles' > joinedColumn='tape_title_id' did not work but joinedColumn='id' did work. Sorry. You'd to use 'artist_id' instead. >>> =======temp.py======= >>> from sqlobject import * >>> #conn = MySQLConnection(user='nigelk', db='music') >>> conn = 'mysql://nigelk@localhost/music' >>> class Artist(SQLObject): >>> _connection = conn >>> Name = StringCol() titles = MultipleJoin('TapeTitle', joinColumn='artist_id') >> >>> class TapeTitle(SQLObject): >>> _connection = conn >>> artist = ForeignKey('Artist') >> IMO, either the docs must be updated or, better yet, SQLobject should >> somehow figure out that joinedColumn argument by itself. |
From: Nigel K. <nig...@or...> - 2004-11-02 15:16:06
|
On 2 Nov 2004, at 14:29, Max Ischenko wrote: > You'd to use 'artist_id' instead. ah! this is beginning to make sense now print Artist.get(2).tapeTitles[0].Title now works properly and has some sense. Presumably titles is ONLY the name of the column in the artist table, it seems to have no other significance. It can't be used? Nigel |
From: Carlos R. <car...@gm...> - 2004-11-02 17:35:40
|
On Tue, 2 Nov 2004 15:16:01 +0000, Nigel King <nig...@or...> wrote: > > On 2 Nov 2004, at 14:29, Max Ischenko wrote: > > > You'd to use 'artist_id' instead. > > ah! this is beginning to make sense now > print Artist.get(2).tapeTitles[0].Title > now works properly and has some sense. Presumably titles is ONLY the > name of the column in the artist table, it seems to have no other > significance. It can't be used? It *has* significance. Try: a = Artist.get(2) print a.titles ...and it will return a list with all titles. Nice, don't you think? The 'artist' x 'artist_id' issue is simple: for every relationship, two fields are created, one referencing the 'id' field of the related table (artist_id, in this case); and the other one returning the entire entity being related to. The 'id' field is needed to make the relationship work. For your own use, you'll probably use the entity for most stuff. As for the need for the joinColumn parameter; in some cases, SQLObject can potentially figure out the correct name for the joinedColumn itself. In some cases, you have to supply it yourself, specially if you use names that are different from the original entity names, or if you have a more complex relationship graph. In your case, I think that SQLObject *could* have found the correct name itself, but then this may be a problem with the 0.6 release, for what I have understood from other answers. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Nigel K. <nig...@or...> - 2004-11-02 20:13:50
|
Carlos, I understand the point about joinColumn=... However, you describe how this did work in version 0.5.2 but unfortunately not in version 0.6. to be absolutely clear =====temp.py==== from sqlobject import * conn = 'mysql://nigelk@localhost/music' class Artist(SQLObject): _connection = conn Name = StringCol() titles = MultipleJoin('TapeTitle',joinColumn='artist_id') class TapeTitle(SQLObject): _connection = conn artist = ForeignKey('Artist') Title = StringCol() a=Artist.get(1) print a.titles ======temp.py====== in terminal [Nigel-Kings-G4:~] nigelk% python temp.py Traceback (most recent call last): File "temp.py", line 16, in ? print a.titles AttributeError: 'Artist' object has no attribute 'titles' This seems to me to be incorrect. The only way that I can print the list that you highlight below is a.tapeTitles I do not understand where this name was came from, it seems like a corruption of TapeTitle. It was available from the dictionary so I tried it. Nigel King On 2 Nov 2004, at 17:35, Carlos Ribeiro wrote: > On Tue, 2 Nov 2004 15:16:01 +0000, Nigel King > <nig...@or...> wrote: >> >> On 2 Nov 2004, at 14:29, Max Ischenko wrote: >> >>> You'd to use 'artist_id' instead. >> >> ah! this is beginning to make sense now >> print Artist.get(2).tapeTitles[0].Title >> now works properly and has some sense. Presumably titles is ONLY the >> name of the column in the artist table, it seems to have no other >> significance. It can't be used? > > It *has* significance. Try: > > a = Artist.get(2) > print a.titles > > ...and it will return a list with all titles. Nice, don't you think? > > The 'artist' x 'artist_id' issue is simple: for every relationship, > two fields are created, one referencing the 'id' field of the related > table (artist_id, in this case); and the other one returning the > entire entity being related to. The 'id' field is needed to make the > relationship work. For your own use, you'll probably use the entity > for most stuff. > > As for the need for the joinColumn parameter; in some cases, SQLObject > can potentially figure out the correct name for the joinedColumn > itself. In some cases, you have to supply it yourself, specially if > you use names that are different from the original entity names, or if > you have a more complex relationship graph. In your case, I think that > SQLObject *could* have found the correct name itself, but then this > may be a problem with the 0.6 release, for what I have understood from > other answers. > > -- > Carlos Ribeiro > Consultoria em Projetos > blog: http://rascunhosrotos.blogspot.com > blog: http://pythonnotes.blogspot.com > mail: car...@gm... > mail: car...@ya... > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Andrew B. <and...@pu...> - 2004-11-02 21:20:19
|
On Tue, Nov 02, 2004 at 08:13:37PM +0000, Nigel King wrote: > Carlos, > I understand the point about joinColumn=... However, you describe how > this did work in version 0.5.2 but unfortunately not in version 0.6. > to be absolutely clear > =====temp.py==== > from sqlobject import * > > conn = 'mysql://nigelk@localhost/music' > > class Artist(SQLObject): > _connection = conn > Name = StringCol() > titles = MultipleJoin('TapeTitle',joinColumn='artist_id') What about if you change this last line to be: titles = MultipleJoin('TapeTitle',joinColumn='artist_id',joinMethodName='titles') ? [...] > This seems to me to be incorrect. > The only way that I can print the list that you highlight below is > > a.tapeTitles > > I do not understand where this name was came from, it seems like a > corruption of TapeTitle. It was available from the dictionary so I > tried it. If this is the joinMethodName bug, then it is fixed in SVN. There is a seperate problem that's been referred to in this thread which is that many people find the existing docs confusing because the examples don't use joinColumn, and rely instead on the SQL having just the right names in it already so that SQLObject automatically guesses them. Judging from the fact you had code working in 0.5.2, I don't think this is relevant to your problem. -Andrew. |
From: Nigel K. <nig...@or...> - 2004-11-03 16:11:17
|
Andrew, Yes thank you that works titles = MultipleJoin('TapeTitle',joinColumn='artist_id',joinMethodName='titles') does that mean that the documentation is incorrect or that sqlobject is incorrect. documentation joinMethodName: When adding joins dynamically (using the class method addJoin), you can give the name of the accessor for the join. It can also be created automatically, and is normally implied (i.e., addresses = MultipleJoin(...) implies joinMethodName="addresses"). Aha I find a discussion reference to the joinMethod bug so I shall assume it will be fixed some time. Nigel King On 2 Nov 2004, at 21:19, Andrew Bennetts wrote: > On Tue, Nov 02, 2004 at 08:13:37PM +0000, Nigel King wrote: >> Carlos, >> I understand the point about joinColumn=... However, you describe how >> this did work in version 0.5.2 but unfortunately not in version 0.6. >> to be absolutely clear >> =====temp.py==== >> from sqlobject import * >> >> conn = 'mysql://nigelk@localhost/music' >> >> class Artist(SQLObject): >> _connection = conn >> Name = StringCol() >> titles = MultipleJoin('TapeTitle',joinColumn='artist_id') > > What about if you change this last line to be: > > titles = > MultipleJoin('TapeTitle',joinColumn='artist_id',joinMethodName='titles' > ) > > ? > > [...] >> This seems to me to be incorrect. >> The only way that I can print the list that you highlight below is >> >> a.tapeTitles >> >> I do not understand where this name was came from, it seems like a >> corruption of TapeTitle. It was available from the dictionary so I >> tried it. > > If this is the joinMethodName bug, then it is fixed in SVN. > > There is a seperate problem that's been referred to in this thread > which is > that many people find the existing docs confusing because the examples > don't > use joinColumn, and rely instead on the SQL having just the right > names in > it already so that SQLObject automatically guesses them. Judging from > the > fact you had code working in 0.5.2, I don't think this is relevant to > your > problem. > > -Andrew. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Andrew B. <an...@ca...> - 2004-11-03 17:06:50
|
On Wed, Nov 03, 2004 at 04:10:49PM +0000, Nigel King wrote: > Andrew, > Yes thank you that works > titles = > MultipleJoin('TapeTitle',joinColumn='artist_id',joinMethodName='titles') > > does that mean that the documentation is incorrect or that sqlobject is > incorrect. It's a bug in the 0.6 release. [...] > > Aha I find a discussion reference to the joinMethod bug so I shall > assume it will be fixed some time. Yes, it's already fixed in SVN. I wonder if a 0.6.1 bugfix release would be worthwhile? -Andrew. |
From: Ian B. <ia...@co...> - 2004-11-03 17:40:26
|
Andrew Bennetts wrote: >>Aha I find a discussion reference to the joinMethod bug so I shall >>assume it will be fixed some time. > > > Yes, it's already fixed in SVN. > > I wonder if a 0.6.1 bugfix release would be worthwhile? I don't feel 100% sure that all the MultipleJoin bugs are worked out. I don't feel exactly clear what they all are. And the documentation that's related. But if that's all cleared up, then I can make another release. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |