From: Oleg B. <ph...@ph...> - 2004-12-01 12:35:29
|
Hello! http://svn.colorstudy.com/home/phd/SQLObject/inheritance/ I've fixed a minor problem with reST in docs/Inheritance.txt. Now I am satisfied with the code, the doc, and the test. I am open for discussion. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian W. <ven...@gm...> - 2006-07-10 22:55:39
|
Hello, I found this inheritance document(http://www.sqlobject.org/Inheritance.html) on the sqlobject site. It looks fantastic. Which version of sqlobject does this apply to? I have something like SQLObject-0.7.1dev_r1457 installed. The document does not seem to say and I can't seem to find the class it refers to. Thanks. -Ian |
From: Ian W. <ven...@gm...> - 2006-07-11 01:29:20
|
Hello again, Sorry, as usual too quick to post. I found it in sqlobject.inheritance as it shows IN the example after I thought long and hard and decided to not be stupid...how embarassing. I'll try it out, thanks. -Ian On 7/10/06, Ian Wilson <ven...@gm...> wrote: > Hello, > I found this inheritance > document(http://www.sqlobject.org/Inheritance.html) on the sqlobject > site. It looks fantastic. Which version of sqlobject does this apply > to? I have something like SQLObject-0.7.1dev_r1457 installed. The > document does not seem to say and I can't seem to find the class it > refers to. Thanks. > -Ian > |
From: Ksenia M. <kse...@gm...> - 2004-12-14 19:03:23
|
> I've fixed a minor problem with reST in docs/Inheritance.txt. Now I > am satisfied with the code, the doc, and the test. > I am open for discussion. I think there is a typo in documentation, in this query: SELECT employee.id, employee.first_name, employee.last_name FROM person, employee WHERE person.first_name = 'Jane' AND employee.position = 'Chief' AND person.id = employee.id It should be "person.first_name, person.last_name" -- Ksenia |
From: Oleg B. <ph...@ph...> - 2004-12-14 20:48:05
|
On Tue, Dec 14, 2004 at 09:03:15PM +0200, Ksenia Marasanova wrote: > I think there is a typo in documentation, in this query: > > SELECT employee.id, employee.first_name, employee.last_name > FROM person, employee WHERE person.first_name = 'Jane' > AND employee.position = 'Chief' AND person.id = employee.id > > It should be "person.first_name, person.last_name" Fixed in the revision 484. Thank you! Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ksenia M. <kse...@gm...> - 2004-12-16 11:16:34
|
Hi, I don't understand how to use an orderBy parameter with this version. Or maybe it's a bug? Given the same example, I can't select employees and order them by first_name. The statement like this: Employee.select(orderBy='first_name') produces: SELECT employee.id, employee.child_name FROM employee WHERE 1 = 1 ORDER BY person.first_name then Postgres reacts to that like 'NOTICE: adding missing FROM-clause entry for table "person"' which results in double number of records in the resultset because the tables are not joined properly. Thanks -- Ksenia. |
From: Ksenia M. <kse...@gm...> - 2004-12-16 11:54:48
|
I must be doing something wrong here, because the documentation example doesn't work for me eather. The problem is that the clause "AND person.id = employee.id" is never added, even when I added search queries for both tables... Here are my class definitions (slightly different names from the doc, but with the same structure): class Person(SQLObject): _inheritable = 1 name = StringCol(length=300, notNone=True) class Author(Person): texts = MultipleJoin('TextAuthor', addRemoveName='Text') And this simple code: Author.select(Person.q.name == 'Ksenia') produces this: SELECT author.id, author.child_name FROM person, author WHERE (person.name = 'Ksenia') Any help would be greatly appreciated :( -- Ksenia. |
From: Oleg B. <ph...@ma...> - 2004-12-16 12:10:01
|
On Thu, Dec 16, 2004 at 01:54:39PM +0200, Ksenia Marasanova wrote: > I must be doing something wrong here Not neccessary. I don't remember if it worked in SQLObject 0.5. And even if it worked the patch can be mangled when we adapted it to 0.6. I'll look into it. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-12-16 14:14:03
Attachments:
inheritance-test1.py
log1
|
On Thu, Dec 16, 2004 at 01:54:39PM +0200, Ksenia Marasanova wrote: > I must be doing something wrong here, because the documentation > example doesn't work for me eather. The problem is that the clause > "AND person.id = employee.id" is never added Look at the attached test and its log. All SELECTs have neccessary AND (employee.id = person.id). Can you reproduce it? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-12-16 14:44:02
|
On Thu, Dec 16, 2004 at 01:16:25PM +0200, Ksenia Marasanova wrote: > Employee.select(orderBy='first_name') > > produces: > > SELECT employee.id, employee.child_name FROM employee WHERE 1 = 1 > ORDER BY person.first_name > > then Postgres reacts to that like 'NOTICE: adding missing FROM-clause > entry for table "person"' > > which results in double number of records in the resultset because the > tables are not joined properly. The problem is that you haven't gave a query clause, and SQLObject cannot decide which tables to use. I am not sure if it is a bug. Try this (with identity clause added to use Person in the query): Employee.select(Person.q.lastName==Person.q.lastName, orderBy=Person.q.firstName) Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ksenia M. <kse...@gm...> - 2004-12-16 16:16:17
|
It helps, SQLObject now adds extra table name to the query, great. But, unfortunately, I still have this missing linking statement(x.id = y.id). This is also the answer to your mail with the test- the test works great! But the existing application still has the problem.. weird. . I also noticed that in the "wrong" sql the table names are switched: ".... from person, employee... " instead of "... from employee, person... " (like in your test). Thanks again -- Ksenia |
From: Oleg B. <ph...@ma...> - 2004-12-16 16:38:25
|
On Thu, Dec 16, 2004 at 06:16:00PM +0200, Ksenia Marasanova wrote: > This is also the answer to your mail with the test- the test works > great! But the existing application still has the problem.. weird. . Ouch! > I also noticed that in the "wrong" sql the table names are switched: > ".... from person, employee... " instead of "... from employee, > person... " (like in your test). The reason for this is that tables are collected in a dictionary, and dictionaries keys are unsorted. There is no difference for an SQL server. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-12-16 19:21:08
Attachments:
orderBy.patch
|
On Thu, Dec 16, 2004 at 05:43:54PM +0300, Oleg Broytmann wrote: > On Thu, Dec 16, 2004 at 01:16:25PM +0200, Ksenia Marasanova wrote: > > Employee.select(orderBy='first_name') > > > > produces: > > > > SELECT employee.id, employee.child_name FROM employee WHERE 1 = 1 > > ORDER BY person.first_name > > > > then Postgres reacts to that like 'NOTICE: adding missing FROM-clause > > entry for table "person"' > > > > which results in double number of records in the resultset because the > > tables are not joined properly. Please try the attached patch and run Employee.select(orderBy=Person.q.firstName) Does it help? Please note that in case you use strings in the query on in the orderBy (orderBy="first_name") it would not work. As was said by Daniel Savard: #DSM: because if the user uses clauseTables #DSM: (and normal string SELECT), he must know what he wants #DSM: and will do himself the relationship between classes. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ksenia M. <kse...@gm...> - 2004-12-23 23:14:08
|
> > Please try the attached patch and run > Employee.select(orderBy=Person.q.firstName) > Does it help? Thank you, for the test case it does produce a correct query: SELECT employee.id, employee.position FROM employee, person WHERE (1 = 1 AND (employee.id = person.id)) ORDER BY person.first_name However, it doesn't have effect on another database. There must be some class / table / property combination in it that SQLObject doesn't like. I'll try to locate the problem by starting with very basic tables and adding the rest piece by piece... Thanks! -- Ksenia |
From: Oleg B. <ph...@ma...> - 2004-12-24 09:30:59
|
On Fri, Dec 24, 2004 at 01:13:57AM +0200, Ksenia Marasanova wrote: > > Please try the attached patch and run > > Employee.select(orderBy=Person.q.firstName) > > Does it help? > > Thank you, for the test case it does produce a correct query: > > SELECT employee.id, employee.position FROM employee, person WHERE (1 > = 1 AND (employee.id = person.id)) ORDER BY person.first_name I've committed the patch at revision 494. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ksenia M. <kse...@gm...> - 2004-12-24 21:27:03
Attachments:
test_inheritance2.py
|
Hi Oleg, Okay, I think I found it. Please try to run the test script, and I hope you'll see that the extra statement (person.id = author.id) is not added... I changed the name of Employee class to Author. This is the most weird part of it... if you change it back to Employee than it works!! Does it have to do something with Python / Postgres reserved keywords?! Cheers, -- Ksenia |
From: Oleg B. <ph...@ph...> - 2004-12-24 21:50:02
|
On Fri, Dec 24, 2004 at 11:26:56PM +0200, Ksenia Marasanova wrote: > Okay, I think I found it. Please try to run the test script, and I > hope you'll see that the extra statement (person.id = author.id) is > not added... It is not. :( > I changed the name of Employee class to Author. This is the most weird > part of it... if you change it back to Employee than it works!! Does > it have to do something with Python / Postgres reserved keywords?! Yes, I see it too. Wierd! I will look into it... Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ksenia M. <kse...@gm...> - 2004-12-25 23:07:15
Attachments:
test_inheritance3.py
|
Here is another bug. The attached script produces this sql: SELECT employee.id, FROM employee WHERE 1 = 1 Greetings, -- Ksenia |
From: Oleg B. <ph...@ph...> - 2004-12-27 10:32:53
|
Hello! On Sun, Dec 26, 2004 at 01:07:07AM +0200, Ksenia Marasanova wrote: > Here is another bug. The attached script produces this sql: > SELECT employee.id, FROM employee WHERE 1 = 1 That one is easy to understand and easy to fix, if it needs to be fixed at all. The problem is not related to inheritance. You've created a table (Employee) that does not have any column - only id. And SQLObject dislikes such a table. With a reason - why does anyone would want a table with only an id column? What is your use case for such a table? Do you want to mark some persons as employees, but don't want to add columns? If there is no a reasonable use case for a columnless table there is no bug to fix - just add a column to tha table Employee and all will work again. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ksenia M. <kse...@gm...> - 2004-12-27 14:04:09
|
> What is your use case for such a table? Do you want to mark some >persons as employees, but don't want to add columns? If there is no a >reasonable use case for a columnless table there is no bug to fix - just >add a column to tha table Employee and all will work again. Sorry, I wanted to simplify the example :) I do have columns, but not a regular ones - MultipleJoin columns. The same error occures. -- Ksenia |
From: Oleg B. <ph...@ph...> - 2004-12-28 08:20:58
|
On Mon, Dec 27, 2004 at 04:04:01PM +0200, Ksenia Marasanova wrote: > Sorry, I wanted to simplify the example :) I do have columns, but not > a regular ones - MultipleJoin columns. The same error occures. This is not related to inheritance. The following simple test triggers the bug in code from SQLObject-trunk: class Person(SQLObject): address = MultipleJoin("Address") class Address(SQLObject): person = ForeignKey("Person") street = StringCol() Person.dropTable(ifExists=True) Person.createTable() Address.dropTable(ifExists=True) Address.createTable() print list(Person.select()) I am going to fix it in the trunk and in the inheritance branch. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ma...> - 2004-12-28 08:42:13
|
On Tue, Dec 28, 2004 at 11:20:48AM +0300, Oleg Broytmann wrote: > I am going to fix it in the trunk and in the inheritance branch. The patch committed at revisions 497 and 498. All tests passed. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-12-28 10:05:11
|
On Fri, Dec 24, 2004 at 11:26:56PM +0200, Ksenia Marasanova wrote: > I changed the name of Employee class to Author. This is the most weird > part of it... if you change it back to Employee than it works!! Does > it have to do something with Python / Postgres reserved keywords?! Not at all. The magic is in the order of registry keys. Registry is a dictionary, and Python handles dictionary's keys in a random order: >>> print {"Author": 1, "Person": 1, "Retired": 1}.keys() ['Person', 'Retired', 'Author'] >>> print {"Employee": 1, "Person": 1, "Retired": 1}.keys() ['Employee', 'Person', 'Retired'] This cause the internal loop that builds the list of parent classes to behave differently. This is a bug, of course, and I'm continuing hunting for it. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2004-12-28 12:16:49
|
On Tue, Dec 28, 2004 at 01:04:56PM +0300, Oleg Broytmann wrote: > This cause the internal loop that builds the list of parent classes > to behave differently. This is a bug, of course, and I'm continuing > hunting for it. Well, I think I've found and nailed the bug. The fix was committed to the inheritance branch at revision 502. Please run your tests and report the results. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ksenia M. <kse...@gm...> - 2004-12-28 21:21:07
|
> Well, I think I've found and nailed the bug. The fix was committed to > the inheritance branch at revision 502. Please run your tests and report > the results. It works like a charm! The statement (person.id = author.id) is now always added. Thank you very much for the fix! It's really cool to have bugs fixed that quickly. I am using inheritance branch for one of the projects and will continue to report any encountered problems. Happy New Year ;-) -- Ksenia |