From: Randall S. <ra...@tn...> - 2005-08-17 01:35:17
|
I'm using the SingleJoin from svn and I think this may be a bug. I'm using SingleJoin like this: individual = SingleJoin('Individual', joinColumn='tinlgent_is_number') But it is not taking the joinColumn. Below is output from the traceback. self.soClass.sqlmeta.columns[attr].dbName, KeyError: 'tinlgentIsNumber' This works with MultipleJoin, but not SingleJoin Randall |
From: Oleg B. <ph...@ma...> - 2005-08-17 11:06:10
|
On Tue, Aug 16, 2005 at 08:34:53PM -0500, Randall Smith wrote: > I'm using the SingleJoin from svn and I think this may be a bug. > > I'm using SingleJoin like this: > > individual = SingleJoin('Individual', joinColumn='tinlgent_is_number') > > But it is not taking the joinColumn. Below is output from the traceback. > > self.soClass.sqlmeta.columns[attr].dbName, > KeyError: 'tinlgentIsNumber' > > This works with MultipleJoin, but not SingleJoin I'd like to hear from the author of SingleJoin about this bug. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: michelts <mic...@gm...> - 2005-08-17 12:15:36
|
Hi, I will check now, soon I will give a reply ;) regards, On 8/17/05, Oleg Broytmann <ph...@ma...> wrote: > On Tue, Aug 16, 2005 at 08:34:53PM -0500, Randall Smith wrote: > > I'm using the SingleJoin from svn and I think this may be a bug. > > > > I'm using SingleJoin like this: > > > > individual =3D SingleJoin('Individual', joinColumn=3D'tinlgent_is_numbe= r') > > > > But it is not taking the joinColumn. Below is output from the tracebac= k. > > > > self.soClass.sqlmeta.columns[attr].dbName, > > KeyError: 'tinlgentIsNumber' > > > > This works with MultipleJoin, but not SingleJoin >=20 > I'd like to hear from the author of SingleJoin about this bug. >=20 > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ ph...@ph... > Programmers don't die, they just GOSUB without RETURN. >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss >=20 --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: michelts <mic...@gm...> - 2005-08-17 13:06:49
Attachments:
joins.py.diff
|
Hi, I check the code, it seems ok, I run test_SingleJoin.py without errors and in this file there is a class that uses joinColumn attribute. Can you send some piece of code to raise the error? I done a fix in SingleJoin, not related to this problem, see below: def __init__(self, makeDefault=3DFalse, **kw): SOMultipleJoin.__init__(self, **kw) self.makeDefault =3D makeDefault def __init__(self, **kw): self.makeDefault =3D kw.pop('makeDefault', False) SOMultipleJoin.__init__(self, **kw) I changed the constructor, it expected the makeDefault attribute before the other attributes, I changed this to the second alternative above: There is a patch attached... On 8/17/05, michelts <mic...@gm...> wrote: > Hi, >=20 > I will check now, soon I will give a reply ;) > regards, >=20 > On 8/17/05, Oleg Broytmann <ph...@ma...> wrote: > > On Tue, Aug 16, 2005 at 08:34:53PM -0500, Randall Smith wrote: > > > I'm using the SingleJoin from svn and I think this may be a bug. > > > > > > I'm using SingleJoin like this: > > > > > > individual =3D SingleJoin('Individual', joinColumn=3D'tinlgent_is_num= ber') > > > > > > But it is not taking the joinColumn. Below is output from the traceb= ack. > > > > > > self.soClass.sqlmeta.columns[attr].dbName, > > > KeyError: 'tinlgentIsNumber' > > > > > > This works with MultipleJoin, but not SingleJoin > > > > I'd like to hear from the author of SingleJoin about this bug. > > > > Oleg. > > -- > > Oleg Broytmann http://phd.pp.ru/ phd@phd.pp.= ru > > Programmers don't die, they just GOSUB without RETURN. > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract= ices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &= QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5= sf > > _______________________________________________ > > sqlobject-discuss mailing list > > sql...@li... > > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > > >=20 >=20 > -- > Michel Thadeu Sabchuk > Curitiba - Brasil >=20 --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: Randall S. <ra...@tn...> - 2005-08-17 14:35:24
Attachments:
sqlojoin.py
|
Attached is an example that fails with SingleJoin but succeeds with MultipleJoin. Make sure to change dbname or the connection string. Randall michelts wrote: > On 8/17/05, Randall Smith <ra...@tn...> wrote: > >>The problem is that it converted tinlgent_is_number to tinlgentIsNumber, >>which it should not do based on the behavior of MultipleJoin. > > > Is it working with MultipleJoin (did you try to replace the SingleJoin > by a MultipleJoin and catch a result?). > > results = self.otherClass.select(getattr( > self.otherClass.q, > self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) > ) == inst.id) > > This is the way the MultipleJoin do the join, it uses the > self.joinColumn trought dbColumnToPythonAttr, I try to simplify it in > SingleJoin: > > pythonColumn = > self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) > results = self.otherClass.select(getattr(self.otherClass.q, > pythonColumn) == inst.id) > > The code is the same, if it works with MultipleJoin it should work > with SingleJoin... > Are you using another style case for the columns? Can you gives me an > working example of the problem? > > regards, > > >>Randall >> >>michelts wrote: >> >>>Hi, >>> >>>I check the code, it seems ok, I run test_SingleJoin.py without errors >>>and in this file there is a class that uses joinColumn attribute. Can >>>you send some piece of code to raise the error? >>> >>>I done a fix in SingleJoin, not related to this problem, see below: >>> >>>def __init__(self, makeDefault=False, **kw): >>> SOMultipleJoin.__init__(self, **kw) >>> self.makeDefault = makeDefault >>> >>>def __init__(self, **kw): >>> self.makeDefault = kw.pop('makeDefault', False) >>> SOMultipleJoin.__init__(self, **kw) >>> >>>I changed the constructor, it expected the makeDefault attribute >>>before the other attributes, I changed this to the second alternative >>>above: >>> >>>There is a patch attached... >>> >>>On 8/17/05, michelts <mic...@gm...> wrote: >>> >>> >>>>Hi, >>>> >>>>I will check now, soon I will give a reply ;) >>>>regards, >>>> >>>>On 8/17/05, Oleg Broytmann <ph...@ma...> wrote: >>>> >>>> >>>>>On Tue, Aug 16, 2005 at 08:34:53PM -0500, Randall Smith wrote: >>>>> >>>>> >>>>>>I'm using the SingleJoin from svn and I think this may be a bug. >>>>>> >>>>>>I'm using SingleJoin like this: >>>>>> >>>>>>individual = SingleJoin('Individual', joinColumn='tinlgent_is_number') >>>>>> >>>>>>But it is not taking the joinColumn. Below is output from the traceback. >>>>>> >>>>>> self.soClass.sqlmeta.columns[attr].dbName, >>>>>>KeyError: 'tinlgentIsNumber' >>>>>> >>>>>>This works with MultipleJoin, but not SingleJoin >>>>> >>>>> I'd like to hear from the author of SingleJoin about this bug. >>>>> >>>>>Oleg. >>>>>-- >>>>> Oleg Broytmann http://phd.pp.ru/ ph...@ph... >>>>> Programmers don't die, they just GOSUB without RETURN. >>>>> >>>>> >>>>>------------------------------------------------------- >>>>>SF.Net email is Sponsored by the Better Software Conference & EXPO >>>>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >>>>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >>>>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >>>>>_______________________________________________ >>>>>sqlobject-discuss mailing list >>>>>sql...@li... >>>>>https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss >>>>> >>>> >>>> >>>>-- >>>>Michel Thadeu Sabchuk >>>>Curitiba - Brasil >>>> >>> >>> >>> >>> >>>------------------------------------------------------------------------ >>> >>>Index: joins.py >>>=================================================================== >>>--- joins.py (revision 915) >>>+++ joins.py (working copy) >>>@@ -238,9 +238,9 @@ >>> >>> class SOSingleJoin(SOMultipleJoin): >>> >>>- def __init__(self, makeDefault=False, **kw): >>>+ def __init__(self, **kw): >>>+ self.makeDefault = kw.pop('makeDefault', False) >>> SOMultipleJoin.__init__(self, **kw) >>>- self.makeDefault = makeDefault >>> >>> def performJoin(self, inst): >>> pythonColumn = self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >> > > |
From: Randall S. <ra...@tn...> - 2005-08-18 19:25:37
|
Think I've got it. The problem is that the SingleJoin class does not correctly determine the name of the foreign key. In the example I attached it determines abnormalPersonID when it should be personID. To correct this I changed the code starting with line 245 of join.py to behave just like a multiple join, except that it still handles the makeDefault option and only returns a single result. If this is good, can a developer commit this to CVS please? Randall Randall Smith wrote: > Attached is an example that fails with SingleJoin but succeeds with > MultipleJoin. > > Make sure to change dbname or the connection string. > > Randall > > michelts wrote: > >> On 8/17/05, Randall Smith <ra...@tn...> wrote: >> >>> The problem is that it converted tinlgent_is_number to tinlgentIsNumber, >>> which it should not do based on the behavior of MultipleJoin. >> >> >> >> Is it working with MultipleJoin (did you try to replace the SingleJoin >> by a MultipleJoin and catch a result?). >> >> results = self.otherClass.select(getattr( >> self.otherClass.q, >> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >> ) == inst.id) >> >> This is the way the MultipleJoin do the join, it uses the >> self.joinColumn trought dbColumnToPythonAttr, I try to simplify it in >> SingleJoin: >> >> pythonColumn = >> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >> results = self.otherClass.select(getattr(self.otherClass.q, >> pythonColumn) == inst.id) >> >> The code is the same, if it works with MultipleJoin it should work >> with SingleJoin... >> Are you using another style case for the columns? Can you gives me an >> working example of the problem? >> >> regards, >> >> >>> Randall >>> >>> michelts wrote: >>> >>>> Hi, >>>> >>>> I check the code, it seems ok, I run test_SingleJoin.py without errors >>>> and in this file there is a class that uses joinColumn attribute. Can >>>> you send some piece of code to raise the error? >>>> >>>> I done a fix in SingleJoin, not related to this problem, see below: >>>> >>>> def __init__(self, makeDefault=False, **kw): >>>> SOMultipleJoin.__init__(self, **kw) >>>> self.makeDefault = makeDefault >>>> >>>> def __init__(self, **kw): >>>> self.makeDefault = kw.pop('makeDefault', False) >>>> SOMultipleJoin.__init__(self, **kw) >>>> >>>> I changed the constructor, it expected the makeDefault attribute >>>> before the other attributes, I changed this to the second alternative >>>> above: >>>> >>>> There is a patch attached... >>>> >>>> On 8/17/05, michelts <mic...@gm...> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I will check now, soon I will give a reply ;) >>>>> regards, >>>>> >>>>> On 8/17/05, Oleg Broytmann <ph...@ma...> wrote: >>>>> >>>>> >>>>>> On Tue, Aug 16, 2005 at 08:34:53PM -0500, Randall Smith wrote: >>>>>> >>>>>> >>>>>>> I'm using the SingleJoin from svn and I think this may be a bug. >>>>>>> >>>>>>> I'm using SingleJoin like this: >>>>>>> >>>>>>> individual = SingleJoin('Individual', >>>>>>> joinColumn='tinlgent_is_number') >>>>>>> >>>>>>> But it is not taking the joinColumn. Below is output from the >>>>>>> traceback. >>>>>>> >>>>>>> self.soClass.sqlmeta.columns[attr].dbName, >>>>>>> KeyError: 'tinlgentIsNumber' >>>>>>> >>>>>>> This works with MultipleJoin, but not SingleJoin >>>>>> >>>>>> >>>>>> I'd like to hear from the author of SingleJoin about this bug. >>>>>> >>>>>> Oleg. >>>>>> -- >>>>>> Oleg Broytmann http://phd.pp.ru/ >>>>>> ph...@ph... >>>>>> Programmers don't die, they just GOSUB without RETURN. >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO >>>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >>>>>> Practices >>>>>> Agile & Plan-Driven Development * Managing Projects & Teams * >>>>>> Testing & QA >>>>>> Security * Process Improvement & Measurement * >>>>>> http://www.sqe.com/bsce5sf >>>>>> _______________________________________________ >>>>>> sqlobject-discuss mailing list >>>>>> sql...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michel Thadeu Sabchuk >>>>> Curitiba - Brasil >>>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> Index: joins.py >>>> =================================================================== >>>> --- joins.py (revision 915) >>>> +++ joins.py (working copy) >>>> @@ -238,9 +238,9 @@ >>>> >>>> class SOSingleJoin(SOMultipleJoin): >>>> >>>> - def __init__(self, makeDefault=False, **kw): >>>> + def __init__(self, **kw): >>>> + self.makeDefault = kw.pop('makeDefault', False) >>>> SOMultipleJoin.__init__(self, **kw) >>>> - self.makeDefault = makeDefault >>>> >>>> def performJoin(self, inst): >>>> pythonColumn = >>>> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >>> >>> >> >> > > > ------------------------------------------------------------------------ > > import psycopg > from sqlobject import * > > dbname = 'mydb' > > connection = connectionForURI("postgres:///%s" % dbname) > __connection__ = connection > > > create_person_sql = """ > CREATE TEMPORARY TABLE person ( > abnormal_person_id serial, > first_name text, > middle_initial char(1), > last_name text > ) > """ > > create_address_sql = """ > CREATE TEMPORARY TABLE address ( > abnormal_address_id serial, > street text, > city text, > state char(2), > zip char(9), > abnormal_person_id int > ) > """ > > class Person(SQLObject): > class sqlmeta: > idName = 'abnormal_person_id' > address = SingleJoin('Address', joinColumn='abnormal_person_id') > ##abnormal_person_id = IntCol() > firstName = StringCol() > middleInitial = StringCol(length=1, default=None) > lastName = StringCol() > > class Address(SQLObject): > class sqlmeta: > idName = 'abnormal_address_id' > ##abnormal_address_id = IntCol() > street = StringCol() > city = StringCol() > state = StringCol(length=2) > zip = StringCol(length=9) > person = ForeignKey('Person', dbName='abnormal_person_id') > > if __name__ == '__main__': > # Create Tables. > connection.query(create_person_sql) > connection.query(create_address_sql) > # Populate. > p = Person(firstName="John", lastName="Doe") > a = Address(person=p, street='111 street', city = 'The City', state='ST', > zip='111111111') > # Test SingleJoin. > result = Person.select(Person.q.lastName == "Doe")[0] > print result.address > |
From: Randall S. <ra...@tn...> - 2005-08-18 19:32:25
|
So this is what the performJoin method looks like: def performJoin(self, inst): results = SOMultipleJoin.performJoin(self, inst) if len(results) == 0: # Same as was before. else: return results[0] Randall Randall Smith wrote: > Think I've got it. The problem is that the SingleJoin class does not > correctly determine the name of the foreign key. In the example I > attached it determines abnormalPersonID when it should be personID. > > To correct this I changed the code starting with line 245 of join.py to > behave just like a multiple join, except that it still handles the > makeDefault option and only returns a single result. If this is good, > can a developer commit this to CVS please? > > Randall > > Randall Smith wrote: > >> Attached is an example that fails with SingleJoin but succeeds with >> MultipleJoin. >> >> Make sure to change dbname or the connection string. >> >> Randall >> >> michelts wrote: >> >>> On 8/17/05, Randall Smith <ra...@tn...> wrote: >>> >>>> The problem is that it converted tinlgent_is_number to >>>> tinlgentIsNumber, >>>> which it should not do based on the behavior of MultipleJoin. >>> >>> >>> >>> >>> Is it working with MultipleJoin (did you try to replace the SingleJoin >>> by a MultipleJoin and catch a result?). >>> >>> results = self.otherClass.select(getattr( >>> self.otherClass.q, >>> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >>> ) == inst.id) >>> >>> This is the way the MultipleJoin do the join, it uses the >>> self.joinColumn trought dbColumnToPythonAttr, I try to simplify it in >>> SingleJoin: >>> >>> pythonColumn = >>> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >>> results = self.otherClass.select(getattr(self.otherClass.q, >>> pythonColumn) == inst.id) >>> >>> The code is the same, if it works with MultipleJoin it should work >>> with SingleJoin... >>> Are you using another style case for the columns? Can you gives me an >>> working example of the problem? >>> >>> regards, >>> >>> >>>> Randall >>>> >>>> michelts wrote: >>>> >>>>> Hi, >>>>> >>>>> I check the code, it seems ok, I run test_SingleJoin.py without errors >>>>> and in this file there is a class that uses joinColumn attribute. Can >>>>> you send some piece of code to raise the error? >>>>> >>>>> I done a fix in SingleJoin, not related to this problem, see below: >>>>> >>>>> def __init__(self, makeDefault=False, **kw): >>>>> SOMultipleJoin.__init__(self, **kw) >>>>> self.makeDefault = makeDefault >>>>> >>>>> def __init__(self, **kw): >>>>> self.makeDefault = kw.pop('makeDefault', False) >>>>> SOMultipleJoin.__init__(self, **kw) >>>>> >>>>> I changed the constructor, it expected the makeDefault attribute >>>>> before the other attributes, I changed this to the second alternative >>>>> above: >>>>> >>>>> There is a patch attached... >>>>> >>>>> On 8/17/05, michelts <mic...@gm...> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I will check now, soon I will give a reply ;) >>>>>> regards, >>>>>> >>>>>> On 8/17/05, Oleg Broytmann <ph...@ma...> wrote: >>>>>> >>>>>> >>>>>>> On Tue, Aug 16, 2005 at 08:34:53PM -0500, Randall Smith wrote: >>>>>>> >>>>>>> >>>>>>>> I'm using the SingleJoin from svn and I think this may be a bug. >>>>>>>> >>>>>>>> I'm using SingleJoin like this: >>>>>>>> >>>>>>>> individual = SingleJoin('Individual', >>>>>>>> joinColumn='tinlgent_is_number') >>>>>>>> >>>>>>>> But it is not taking the joinColumn. Below is output from the >>>>>>>> traceback. >>>>>>>> >>>>>>>> self.soClass.sqlmeta.columns[attr].dbName, >>>>>>>> KeyError: 'tinlgentIsNumber' >>>>>>>> >>>>>>>> This works with MultipleJoin, but not SingleJoin >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'd like to hear from the author of SingleJoin about this bug. >>>>>>> >>>>>>> Oleg. >>>>>>> -- >>>>>>> Oleg Broytmann http://phd.pp.ru/ >>>>>>> ph...@ph... >>>>>>> Programmers don't die, they just GOSUB without RETURN. >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------- >>>>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO >>>>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >>>>>>> Practices >>>>>>> Agile & Plan-Driven Development * Managing Projects & Teams * >>>>>>> Testing & QA >>>>>>> Security * Process Improvement & Measurement * >>>>>>> http://www.sqe.com/bsce5sf >>>>>>> _______________________________________________ >>>>>>> sqlobject-discuss mailing list >>>>>>> sql...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michel Thadeu Sabchuk >>>>>> Curitiba - Brasil >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> >>>>> Index: joins.py >>>>> =================================================================== >>>>> --- joins.py (revision 915) >>>>> +++ joins.py (working copy) >>>>> @@ -238,9 +238,9 @@ >>>>> >>>>> class SOSingleJoin(SOMultipleJoin): >>>>> >>>>> - def __init__(self, makeDefault=False, **kw): >>>>> + def __init__(self, **kw): >>>>> + self.makeDefault = kw.pop('makeDefault', False) >>>>> SOMultipleJoin.__init__(self, **kw) >>>>> - self.makeDefault = makeDefault >>>>> >>>>> def performJoin(self, inst): >>>>> pythonColumn = >>>>> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >>>> >>>> >>>> >>> >>> >> >> >> ------------------------------------------------------------------------ >> >> import psycopg >> from sqlobject import * >> >> dbname = 'mydb' >> >> connection = connectionForURI("postgres:///%s" % dbname) >> __connection__ = connection >> >> >> create_person_sql = """ >> CREATE TEMPORARY TABLE person ( >> abnormal_person_id serial, >> first_name text, >> middle_initial char(1), >> last_name text >> ) >> """ >> >> create_address_sql = """ >> CREATE TEMPORARY TABLE address ( >> abnormal_address_id serial, >> street text, >> city text, >> state char(2), >> zip char(9), >> abnormal_person_id int >> ) >> """ >> >> class Person(SQLObject): >> class sqlmeta: >> idName = 'abnormal_person_id' >> address = SingleJoin('Address', joinColumn='abnormal_person_id') >> ##abnormal_person_id = IntCol() >> firstName = StringCol() >> middleInitial = StringCol(length=1, default=None) >> lastName = StringCol() >> >> class Address(SQLObject): >> class sqlmeta: >> idName = 'abnormal_address_id' >> ##abnormal_address_id = IntCol() >> street = StringCol() >> city = StringCol() >> state = StringCol(length=2) >> zip = StringCol(length=9) >> person = ForeignKey('Person', dbName='abnormal_person_id') >> >> if __name__ == '__main__': >> # Create Tables. >> connection.query(create_person_sql) >> connection.query(create_address_sql) >> # Populate. >> p = Person(firstName="John", lastName="Doe") >> a = Address(person=p, street='111 street', city = 'The City', >> state='ST', >> zip='111111111') >> # Test SingleJoin. >> result = Person.select(Person.q.lastName == "Doe")[0] >> print result.address >> |
From: Oleg B. <ph...@ph...> - 2005-08-18 08:06:41
|
On Wed, Aug 17, 2005 at 10:06:39AM -0300, michelts wrote: > - def __init__(self, makeDefault=False, **kw): > + def __init__(self, **kw): > + self.makeDefault = kw.pop('makeDefault', False) > SOMultipleJoin.__init__(self, **kw) > - self.makeDefault = makeDefault Applied, though not exactly in this way. SQLObject promises to retain Python 2.2 compatibility, so I replaced kw.pop() with our popKey() function. Committed at revision 918. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Randall S. <ra...@tn...> - 2005-08-18 18:25:58
|
If on line 247 of join.py, I use self.joinColumn instead of pythonColumn, it works fine. Randall Randall Smith wrote: > Attached is an example that fails with SingleJoin but succeeds with > MultipleJoin. > > Make sure to change dbname or the connection string. > > Randall > > michelts wrote: > >> On 8/17/05, Randall Smith <ra...@tn...> wrote: >> >>> The problem is that it converted tinlgent_is_number to tinlgentIsNumber, >>> which it should not do based on the behavior of MultipleJoin. >> >> >> >> Is it working with MultipleJoin (did you try to replace the SingleJoin >> by a MultipleJoin and catch a result?). >> >> results = self.otherClass.select(getattr( >> self.otherClass.q, >> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >> ) == inst.id) >> >> This is the way the MultipleJoin do the join, it uses the >> self.joinColumn trought dbColumnToPythonAttr, I try to simplify it in >> SingleJoin: >> >> pythonColumn = >> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >> results = self.otherClass.select(getattr(self.otherClass.q, >> pythonColumn) == inst.id) >> >> The code is the same, if it works with MultipleJoin it should work >> with SingleJoin... >> Are you using another style case for the columns? Can you gives me an >> working example of the problem? >> >> regards, >> >> >>> Randall >>> >>> michelts wrote: >>> >>>> Hi, >>>> >>>> I check the code, it seems ok, I run test_SingleJoin.py without errors >>>> and in this file there is a class that uses joinColumn attribute. Can >>>> you send some piece of code to raise the error? >>>> >>>> I done a fix in SingleJoin, not related to this problem, see below: >>>> >>>> def __init__(self, makeDefault=False, **kw): >>>> SOMultipleJoin.__init__(self, **kw) >>>> self.makeDefault = makeDefault >>>> >>>> def __init__(self, **kw): >>>> self.makeDefault = kw.pop('makeDefault', False) >>>> SOMultipleJoin.__init__(self, **kw) >>>> >>>> I changed the constructor, it expected the makeDefault attribute >>>> before the other attributes, I changed this to the second alternative >>>> above: >>>> >>>> There is a patch attached... >>>> >>>> On 8/17/05, michelts <mic...@gm...> wrote: >>>> >>>> >>>>> Hi, >>>>> >>>>> I will check now, soon I will give a reply ;) >>>>> regards, >>>>> >>>>> On 8/17/05, Oleg Broytmann <ph...@ma...> wrote: >>>>> >>>>> >>>>>> On Tue, Aug 16, 2005 at 08:34:53PM -0500, Randall Smith wrote: >>>>>> >>>>>> >>>>>>> I'm using the SingleJoin from svn and I think this may be a bug. >>>>>>> >>>>>>> I'm using SingleJoin like this: >>>>>>> >>>>>>> individual = SingleJoin('Individual', >>>>>>> joinColumn='tinlgent_is_number') >>>>>>> >>>>>>> But it is not taking the joinColumn. Below is output from the >>>>>>> traceback. >>>>>>> >>>>>>> self.soClass.sqlmeta.columns[attr].dbName, >>>>>>> KeyError: 'tinlgentIsNumber' >>>>>>> >>>>>>> This works with MultipleJoin, but not SingleJoin >>>>>> >>>>>> >>>>>> I'd like to hear from the author of SingleJoin about this bug. >>>>>> >>>>>> Oleg. >>>>>> -- >>>>>> Oleg Broytmann http://phd.pp.ru/ >>>>>> ph...@ph... >>>>>> Programmers don't die, they just GOSUB without RETURN. >>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> SF.Net email is Sponsored by the Better Software Conference & EXPO >>>>>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle >>>>>> Practices >>>>>> Agile & Plan-Driven Development * Managing Projects & Teams * >>>>>> Testing & QA >>>>>> Security * Process Improvement & Measurement * >>>>>> http://www.sqe.com/bsce5sf >>>>>> _______________________________________________ >>>>>> sqlobject-discuss mailing list >>>>>> sql...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michel Thadeu Sabchuk >>>>> Curitiba - Brasil >>>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> Index: joins.py >>>> =================================================================== >>>> --- joins.py (revision 915) >>>> +++ joins.py (working copy) >>>> @@ -238,9 +238,9 @@ >>>> >>>> class SOSingleJoin(SOMultipleJoin): >>>> >>>> - def __init__(self, makeDefault=False, **kw): >>>> + def __init__(self, **kw): >>>> + self.makeDefault = kw.pop('makeDefault', False) >>>> SOMultipleJoin.__init__(self, **kw) >>>> - self.makeDefault = makeDefault >>>> >>>> def performJoin(self, inst): >>>> pythonColumn = >>>> self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) >>> >>> >> >> > > > ------------------------------------------------------------------------ > > import psycopg > from sqlobject import * > > dbname = 'mydb' > > connection = connectionForURI("postgres:///%s" % dbname) > __connection__ = connection > > > create_person_sql = """ > CREATE TEMPORARY TABLE person ( > abnormal_person_id serial, > first_name text, > middle_initial char(1), > last_name text > ) > """ > > create_address_sql = """ > CREATE TEMPORARY TABLE address ( > abnormal_address_id serial, > street text, > city text, > state char(2), > zip char(9), > abnormal_person_id int > ) > """ > > class Person(SQLObject): > class sqlmeta: > idName = 'abnormal_person_id' > address = SingleJoin('Address', joinColumn='abnormal_person_id') > ##abnormal_person_id = IntCol() > firstName = StringCol() > middleInitial = StringCol(length=1, default=None) > lastName = StringCol() > > class Address(SQLObject): > class sqlmeta: > idName = 'abnormal_address_id' > ##abnormal_address_id = IntCol() > street = StringCol() > city = StringCol() > state = StringCol(length=2) > zip = StringCol(length=9) > person = ForeignKey('Person', dbName='abnormal_person_id') > > if __name__ == '__main__': > # Create Tables. > connection.query(create_person_sql) > connection.query(create_address_sql) > # Populate. > p = Person(firstName="John", lastName="Doe") > a = Address(person=p, street='111 street', city = 'The City', state='ST', > zip='111111111') > # Test SingleJoin. > result = Person.select(Person.q.lastName == "Doe")[0] > print result.address > |
From: Oleg B. <ph...@ph...> - 2005-08-19 06:05:44
|
On Thu, Aug 18, 2005 at 11:28:09AM -0500, Randall Smith wrote: > So this is what the performJoin method looks like: > > def performJoin(self, inst): > > results = SOMultipleJoin.performJoin(self, inst) > > if len(results) == 0: > # Same as was before. > else: > return results[0] Michael, any opinion on this? Randall, can you please stop quoting (and stop top-quote) entire messages? I am a bit drowned in the flood (I am out of town with my notebook, and I am on a very slooow and very expensive GPRS connection). Thank you. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: michelts <mic...@gm...> - 2005-08-19 12:41:34
Attachments:
sqlojoin.py
|
Hi guys, Sorry to be to late :), I'm in tests week in university... Well, lets dig up, this is really a problem: You don't need to use joinColumn with SingleJoin or SQLMultipleJoin in this case, I attached your example with the correction. The reason for this is that the results are not made by a raw query on the database, instead it is generated throught sqlbuilder: ... pythonColumn =3D self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) results =3D self.otherClass.select(getattr(self.otherClass.q, pythonColumn) =3D=3D inst.id) # OtherClass.select(OtherClass.q.myClassID=3D=3DMyClass. ... The attribute in address table is person, sqlobject internally create a personID attribute, so in a select you can use: Address.select(Address.q.personID=3D=3Did) I couldn't found another way to wonder how to hit this attribute. Look at the "getattr(self.otherClass.q, pythonColumn)" it will look likes "Address.q.personID"... > > So this is what the performJoin method looks like: > > > > def performJoin(self, inst): > > > > results =3D SOMultipleJoin.performJoin(self, inst) > > > > if len(results) =3D=3D 0: > > # Same as was before. > > else: > > return results[0] I look at how performJoin works, it sends a raw query to the database, I can use something like this (replacing the first code): ... # pythonColumn =3D self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) # results =3D self.otherClass.select(getattr(self.otherClass.q, pythonColumn) =3D=3D inst.id) sqlrepr =3D self._connection.sqlrepr results =3D self.otherClass.select('%s =3D %s' % (self.joinColumn, sqlrepr(inst.id))) ... This way the first code works and I don't waste the functionality of the selectResult. > Michael, any opinion on this? Michel :) What do you think Oleg and Randall? Which solution is the more appropriated= ? I will generate the patch to the second solution anyway, let me check if the RelatedJoin doesn't have problems too... regards, and sorry my late response or sorry if I was confusing... --=20 Michel Thadeu Sabchuk Curitiba - Brasil |
From: Randall S. <ra...@tn...> - 2005-08-19 20:16:51
|
I tried this: > # pythonColumn = > self.soClass.sqlmeta.style.dbColumnToPythonAttr(self.joinColumn) > # results = self.otherClass.select(getattr(self.otherClass.q, > pythonColumn) == inst.id) > sqlrepr = self._connection.sqlrepr > results = self.otherClass.select('%s = %s' % (self.joinColumn, > sqlrepr(inst.id))) Changed sqlrepr line to get the connection. But got this: psycopg.ProgrammingError: ERROR: invalid input syntax for type boolean: "person_id = 1" SELECT address.abnormal_address_id, address.street, address.city, address.state, address.zip, address.abnormal_person_id FROM address WHERE ('person_id = 1' AND (address.city = 'City')) LIMIT 1 Randall |
From: Randall S. <ra...@tn...> - 2005-08-21 01:43:43
|
michelts wrote: > What do you think Oleg and Randall? Which solution is the more appropriated? > I will generate the patch to the second solution anyway, let me check > if the RelatedJoin doesn't have problems too... Think I have a solution I'm happy with. I handled it in my Style by defining dbColumnToPythonAttr to catch key fields and transform them. For example, tinwsys_is_number returns as tinwsysID. The Join code is unchanged. Enjoying SQLObject! Randall |