Re: [SQLObject] MultipleJoin inactive in version 0.6

[Nigel K. <nig...@or...>]

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
>