sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Andrew B. <an...@ca...>]

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.

Re: [SQLObject] MultipleJoin inactive in version 0.6

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

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
>

Fwd: Re: [SQLObject] ForeignKey...

[Philippe N. <sw...@fr...>]

Le 2/11/2004, "Michel Thadeu" <mic...@ya...> a =E9crit:

>Hi guys,
>
>I have 2 tables, question and reply:
>
>class Question(SQLObject):
>   content=3DStringCol()
>   parent=3DForeignKey('Reply')
>   childs=3DMultipleJoin('Reply')
>
>class Reply(SQLObject):
>   content=3DStringCol()
>   parent=3DForeignKey('Question')
>   childs=3DMultipleJoin('Question')
>
>One question can has infinite replies and one reply can has infinite
>subquestions, if my user don't understand the reply... I using
>SQLObject from svn with postgresql.
>
>

Use a RelatedJoin ?

class Question(SQLObject):
   content =3D StringCol()
   replies =3D RelatedJoin('Reply')

class Reply(SQLObject):
    content =3D StringCol()
    questions =3D RelatedJoin('Question')

Philippe

Re: [SQLObject] ForeignKey...

[Philippe N. <ph...@re...>]

Le 2/11/2004, "Michel Thadeu" <mic...@ya...> a =E9crit:

>Hi guys,
>
>I have 2 tables, question and reply:
>
>class Question(SQLObject):
>   content=3DStringCol()
>   parent=3DForeignKey('Reply')
>   childs=3DMultipleJoin('Reply')
>
>class Reply(SQLObject):
>   content=3DStringCol()
>   parent=3DForeignKey('Question')
>   childs=3DMultipleJoin('Question')
>
>One question can has infinite replies and one reply can has infinite
>subquestions, if my user don't understand the reply... I using
>SQLObject from svn with postgresql.
>
>

Use a RelatedJoin ?

class Question(SQLObject):
   content =3D StringCol()
   replies =3D RelatedJoin('Reply')

class Reply(SQLObject):
    content =3D StringCol()
    questions =3D RelatedJoin('Question')

Philippe

[SQLObject] Re: DBConnection for MS SQL Server / MSDE

[Joseph K. <jko...@ma...>]

On 2004-11-02 15:37:47 -0700, Ian Bicking <ia...@co...> said:

> Joseph Kocherhans wrote:
>> On 2004-11-01 14:05:17 -0700, Ian Bicking <ia...@co...> said:
>> 
>>> Sean M. Hester wrote:
>>> 
>>>> I checked the archives for "SQL Server" and "SQLServer" but didn't find
>>>> anything--my apologies if I'm needlessly rehashing an old topic.
>>>> Anyway...has anyone already worked on providing DBConnection compatibility
>>>> with MS's SQL Server 2K or MSDE? If so, would you care to share? If not, are
>>>> other parties interested if I wind up going down the rabbit hole?
>>> 
>>> 
>>> There's some code in 
>>> svn://colorstudy.com/home/jkocherhans/SQLObject-mssql-branch , I 
>>> haven't looked at it at all, so I don't know more.
>> 
>> 
>> That branch uses mxODBC, so it *does* require some non-free software. I 
>> was never able to find another stable way to connect to SQL Server from 
>> python.
> 
> Did you try SQLRelay (sqlrelay.sf.net)?  I haven't tried it, but it 
> seems like a possible solution.  I think I also saw something recently 
> (on PyPI?) that used a similar client-server setup, where you put some 
> sort of simple server on the Windows box, and then there's a client 
> that implements the DB API.

I didn't. Everything I tried was either ODBC based, or psycopg type 
da's. SQLRelay looks promising though.

> If you're on Windows natively, I guess there's another odbc 
> implementation in win32all, and there's a DB API driver that runs off 
> of ADO, which I think you can use through COM.

I haven't tried those either as I was looking for something that would 
work for *nix.

Joseph

[SQLObject] Re: DBConnection for MS SQL Server / MSDE

[Sean M. H. <str...@ma...>]

Thanks to Ian and Joseph--particularly for Joseph's detailed efforts in this
area. I'll take a look, and may have to consider using mxODBC if necessary.
In the near-term the path of least resistance looks most appropriate, but if
I do learn anything I'll happily share. Sometimes you have to hold hands
with the devil. ;)

Sean

> Message: 13
> To: sql...@li...
> From: Joseph Kocherhans <jko...@ma...>
> Date: Tue, 2 Nov 2004 14:59:44 -0700
> Subject: [SQLObject] Re: DBConnection for MS SQL Server / MSDE
> 
> On 2004-11-01 14:05:17 -0700, Ian Bicking <ia...@co...> said:
> 
>> Sean M. Hester wrote:
>>> I checked the archives for "SQL Server" and "SQLServer" but didn't find
>>> anything--my apologies if I'm needlessly rehashing an old topic.
>>> Anyway...has anyone already worked on providing DBConnection compatibility
>>> with MS's SQL Server 2K or MSDE? If so, would you care to share? If not, are
>>> other parties interested if I wind up going down the rabbit hole?
>> 
>> There's some code in
>> svn://colorstudy.com/home/jkocherhans/SQLObject-mssql-branch , I
>> haven't looked at it at all, so I don't know more.
> 
> That branch uses mxODBC, so it *does* require some non-free software. I
> was never able to find another stable way to connect to SQL Server from
> python. I did all of the testing with iODBC and FreeTDS on OS X and
> Linux. It's a point where all but 3 tests pass. (and those are cursor
> splitting tests IIRC) Eventually I ran into threading/pooling issues
> with a zope3 DA I wrote on top of it, but for simple stuff it was
> working fine. I never did track down where the threading issues came
> into play though. I pretty much gave up and moved over to postgres +
> some scripts to replicate the sql server data nightly. Feel free to
> check it out and ask questions.
> 
> Joseph
> 
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 
> 
> End of sqlobject-discuss Digest

Re: [SQLObject] Re: DBConnection for MS SQL Server / MSDE

[Ian B. <ia...@co...>]

Joseph Kocherhans wrote:
> On 2004-11-01 14:05:17 -0700, Ian Bicking <ia...@co...> said:
> 
>> Sean M. Hester wrote:
>>
>>> I checked the archives for "SQL Server" and "SQLServer" but didn't find
>>> anything--my apologies if I'm needlessly rehashing an old topic.
>>> Anyway...has anyone already worked on providing DBConnection 
>>> compatibility
>>> with MS's SQL Server 2K or MSDE? If so, would you care to share? If 
>>> not, are
>>> other parties interested if I wind up going down the rabbit hole?
>>
>>
>> There's some code in 
>> svn://colorstudy.com/home/jkocherhans/SQLObject-mssql-branch , I 
>> haven't looked at it at all, so I don't know more.
> 
> 
> That branch uses mxODBC, so it *does* require some non-free software. I 
> was never able to find another stable way to connect to SQL Server from 
> python. 

Did you try SQLRelay (sqlrelay.sf.net)?  I haven't tried it, but it 
seems like a possible solution.  I think I also saw something recently 
(on PyPI?) that used a similar client-server setup, where you put some 
sort of simple server on the Windows box, and then there's a client that 
implements the DB API.

If you're on Windows natively, I guess there's another odbc 
implementation in win32all, and there's a DB API driver that runs off of 
ADO, which I think you can use through COM.

But I've never actually tried any of these.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

[SQLObject] ForeignKey...

[Michel T. <mic...@ya...>]

Hi guys,

I have 2 tables, question and reply:

class Question(SQLObject):
   content=StringCol()
   parent=ForeignKey('Reply')
   childs=MultipleJoin('Reply')

class Reply(SQLObject):
   content=StringCol()
   parent=ForeignKey('Question')
   childs=MultipleJoin('Question')

One question can has infinite replies and one reply can has infinite
subquestions, if my user don't understand the reply... I using
SQLObject from svn with postgresql.

I have an error when trying to create the database because the foreign
key are checked on the database. I can't create question unless the
reply exists and vice versa.

What can I do to avoid this checking?

Thanks any help, sorry my poor english...

=====
--
Michel Thadeu Sabchuk
Curitiba/PR


	
	
		
_______________________________________________________ 
Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

[SQLObject] Re: DBConnection for MS SQL Server / MSDE

[Joseph K. <jko...@ma...>]

On 2004-11-01 14:05:17 -0700, Ian Bicking <ia...@co...> said:

> Sean M. Hester wrote:
>> I checked the archives for "SQL Server" and "SQLServer" but didn't find
>> anything--my apologies if I'm needlessly rehashing an old topic.
>> Anyway...has anyone already worked on providing DBConnection compatibility
>> with MS's SQL Server 2K or MSDE? If so, would you care to share? If not, are
>> other parties interested if I wind up going down the rabbit hole?
> 
> There's some code in 
> svn://colorstudy.com/home/jkocherhans/SQLObject-mssql-branch , I 
> haven't looked at it at all, so I don't know more.

That branch uses mxODBC, so it *does* require some non-free software. I 
was never able to find another stable way to connect to SQL Server from 
python. I did all of the testing with iODBC and FreeTDS on OS X and 
Linux. It's a point where all but 3 tests pass. (and those are cursor 
splitting tests IIRC) Eventually I ran into threading/pooling issues 
with a zope3 DA I wrote on top of it, but for simple stuff it was 
working fine. I never did track down where the threading issues came 
into play though. I pretty much gave up and moved over to postgres + 
some scripts to replicate the sql server data nightly. Feel free to 
check it out and ask questions.

Joseph

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Andrew B. <and...@pu...>]

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.

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
>

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Carlos R. <car...@gm...>]

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...

Re: [SQLObject] MultipleJoin inactive in version 0.6

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

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

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Max I. <ma...@uc...>]

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.

Re: [SQLObject] MultipleJoin inactive in version 0.6

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

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
>

Re: [SQLObject] Plan (was: MultipleJoin inactive in version 0.6)

[Oleg B. <ph...@ma...>]

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.

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Andrew B. <and...@pu...>]

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.

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Carlos R. <car...@gm...>]

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...

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Oleg B. <ph...@ma...>]

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.

Re: [SQLObject] MultipleJoin inactive in version 0.6

[Max I. <ma...@uc...>]

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.

[SQLObject] MultipleJoin inactive in version 0.6

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

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

Re: [SQLObject] MySQLConnection is deprecated

[Ian B. <ia...@co...>]

David M. Cook wrote:
> On Mon, Nov 01, 2004 at 03:04:28PM -0600, Ian Bicking wrote:
>>I just haven't reviewed the documentation since then.  Though I'm not 
>>100% sure that MySQLConnection and friends should be deprecated.
> 
> Maybe I'm wrong, but the URI format doesn't seem very win32 friendly.

How so?  Forward slashes can always replace backslashes for paths (and 
even that only applies to SQLite and Firebird, since the other databases 
don't use file paths anywhere).

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] MySQLConnection is deprecated

[David M. C. <da...@da...>]

On Mon, Nov 01, 2004 at 03:04:28PM -0600, Ian Bicking wrote:

> I just haven't reviewed the documentation since then.  Though I'm not 
> 100% sure that MySQLConnection and friends should be deprecated.

Maybe I'm wrong, but the URI format doesn't seem very win32 friendly.

Dave Cook

Re: [SQLObject] DBConnection for MS SQL Server / MSDE

[Ian B. <ia...@co...>]

Sean M. Hester wrote:
> I checked the archives for "SQL Server" and "SQLServer" but didn't find
> anything--my apologies if I'm needlessly rehashing an old topic.
> Anyway...has anyone already worked on providing DBConnection compatibility
> with MS's SQL Server 2K or MSDE? If so, would you care to share? If not, are
> other parties interested if I wind up going down the rabbit hole?

There's some code in 
svn://colorstudy.com/home/jkocherhans/SQLObject-mssql-branch , I haven't 
looked at it at all, so I don't know more.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] MySQLConnection is deprecated

[Ian B. <ia...@co...>]

Nigel King wrote:
> I get the following warning on my MySQLConnection
> 
> /usr/local/lib/python2.3/site-packages/sqlobject/__init__.py:23: 
> DeprecationWarning: MySQLConnection is deprecated; use 
> connectionForURI("mysql://...") or "from sqlobject.mysql import builder; 
> MySQLConnection = builder()"
>   _warn('MySQLConnection is deprecated; use 
> connectionForURI("mysql://...") or "from sqlobject.mysql import builder; 
> MySQLConnection = builder()"')
> 
> In the manual it says to use
> conn = MySQLConnection(user='test', db='testdb')
> which is the method I use.
> 
> What is actually intended?

I just haven't reviewed the documentation since then.  Though I'm not 
100% sure that MySQLConnection and friends should be deprecated.

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org