Menu
▾
▴
pymerase-devel — Pymerase Development List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(5) |
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(11) |
Feb
(5) |
Mar
(12) |
Apr
(32) |
May
(15) |
Jun
(16) |
Jul
(22) |
Aug
(30) |
Sep
(8) |
Oct
(4) |
Nov
|
Dec
(12) |
| 2004 |
Jan
(14) |
Feb
(1) |
Mar
(5) |
Apr
(3) |
May
(5) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(13) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2007-07-22 16:08:08
|
Feature Requests item #1758487, was opened at 2007-07-22 09:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1758487&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Input: parseXMI Group: None Status: Open Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add MagicDraw UML Support Initial Comment: MagicDraw is very popular and used within many open source projects. Please consider making Pymerase compatible. Anybody doing such work would receive a complementary copy of MagicDraw. Please contact danielb [at] nomagic [dots] com. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1758487&group_id=63836 |
|
From: Cory T. <ube...@gm...> - 2006-07-19 01:28:58
|
> As far as I can tell, we only switched pymerase from pgdb to psycopg, > I'm not sure if I ever bothered to upgrade to psycopg2 pymerase definitely still uses psycopg1. To use psycopg2, one needs to explicitly import psycopg2. All of the dbAPIs import the original... "import psycopg". For the most part it's just a matter of going through and adding a 2 to the end of all the import statements but there are a few cases (such as serialize=0) where some work is involved. > Upgrading to psychopg2 does sound like a good idea, though i'm not > sure when we could get around to it. No need to hurry, psycopg 1 still works just fine. It's just a pain to install. Eg. it doesn't even look in /usr/include for the postgres headers. It just waits for you to tell it that, yes, the headers _are_ installed to the default directory. Cory |
|
From: Diane T. <di...@ca...> - 2006-07-19 00:55:50
|
As far as I can tell, we only switched pymerase from pgdb to psycopg, I'm not sure if I ever bothered to upgrade to psycopg2 Upgrading to psychopg2 does sound like a good idea, though i'm not sure when we could get around to it. diane |
|
From: SourceForge.net <no...@so...> - 2005-12-01 19:09:20
|
Feature Requests item #1371137, was opened at 2005-12-01 11:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1371137&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: None Status: Open Priority: 5 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: Disk based transaction manager: gziped temp file Initial Comment: The disk based transaction manager can create large temperary files. It would be nice to have an option to have this file be compressed by default so it doesn't take up so much space. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1371137&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-12-01 19:07:58
|
Feature Requests item #1371135, was opened at 2005-12-01 11:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1371135&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: None Status: Open Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: Disk based transaction manager: Selectable tmp dir Initial Comment: It would be helpful if the diskbased transaction manager had an optional argument which would allow you to choose the tmp directory for it to use. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1371135&group_id=63836 |
|
From: Brandon K. <ki...@ca...> - 2005-08-16 00:43:03
|
The transaction manager now supports storing the sql_statements on disk rather then in memory. Now you can use the new disk based transaction manager by calling: tm = dbs.createTransactionManager(disk_based=True) #Default = False |
|
From: SourceForge.net <no...@so...> - 2005-08-16 00:38:34
|
Feature Requests item #1260456, was opened at 2005-08-15 17:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1260456&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: None Status: Open Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Nobody/Anonymous (nobody) Summary: Disk based transaction manager Initial Comment: It would be nice to have the option of having the transaction manager to store the sql statements on disk rather than in memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=1260456&group_id=63836 |
|
From: Brandon K. <ki...@ca...> - 2005-08-15 21:45:53
|
I took Diane's advice and added a global variable in the dbAPI module called INCLUDE_WARN_CALLS, which by default is set to false. Now almost all warn calls won't happen unless you import dbAPI setting dbAPI.INCLUDE_WARN_CALLS to True. This seems to have created about a 30% increase in speed! |
|
From: SourceForge.net <no...@so...> - 2005-08-15 21:30:32
|
Bugs item #1260317, was opened at 2005-08-15 14:16 Message generated for change (Settings changed) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1260317&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2.1 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: dbAPI warn() calls takes up ~30% of CPU time in dbAPI.py Initial Comment: I noticed that when using the profile module to check the number of calls and time of calls, the warn function takes up about ~30% of the CPU time. ---------------------------------------------------------------------- >Comment By: Brandon King (kingb) Date: 2005-08-15 14:30 Message: Logged In: YES user_id=552216 I took Diane's advice and added a global variable in the dbAPI module called INCLUDE_WARN_CALLS, which by default is set to false. Now almost all warn calls won't happen unless you import dbAPI setting dbAPI.INCLUDE_WARN_CALLS to True. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1260317&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-08-15 21:17:00
|
Bugs item #1260317, was opened at 2005-08-15 14:16 Message generated for change (Settings changed) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1260317&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI >Group: v0.2.1 Status: Open Resolution: None Priority: 9 Submitted By: Brandon King (kingb) >Assigned to: Brandon King (kingb) Summary: dbAPI warn() calls takes up ~30% of CPU time in dbAPI.py Initial Comment: I noticed that when using the profile module to check the number of calls and time of calls, the warn function takes up about ~30% of the CPU time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1260317&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-08-15 21:16:39
|
Bugs item #1260317, was opened at 2005-08-15 14:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1260317&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Nobody/Anonymous (nobody) Summary: dbAPI warn() calls takes up ~30% of CPU time in dbAPI.py Initial Comment: I noticed that when using the profile module to check the number of calls and time of calls, the warn function takes up about ~30% of the CPU time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1260317&group_id=63836 |
|
From: Brandon K. <ki...@ca...> - 2005-08-15 21:07:49
|
I've checked in a major memory leak bug fix into CVS and is available on http://pymerase.caltech.edu. I've created ten unittests which pass now after the patch and did some additional tests. I still may need more testing. If any new bugs are found, please submit a bug report. If anyone would like more information about how to take advantage of the new memory saving abilities, please send a message to the mailing lists. Enjoy! DETAILS: Fixes for bugs 1256258 and 1256271. Memory leak should now be fixed. Ten test cases have be implemented in tests/TestMemLeak.py... All ten pass currently. I tested for slow down in creating and commiting 10,000 objects to a database. It has a 0.2 sec slow down in a 94 sec time frame. The fix includes an object cache which reuses objects which have already been pulled into memory (using weakrefs). Also, there is a new function for DBClass objects called _destroySelf. This function must be called before calling del on an DBClass object. This is only useful when you want to free up some memory when your done with a DBClass object, but the program is going to continue to run. It works by removing all references to the class your trying to remove so that the python ref count will be low enough for garbage collection to free up the memory. Calling del without calling _destroySelf will NOT remove the object from memory. To go back to the memory leaky version check out tag 'pre_aug_2005_mem_patch'. |
|
From: SourceForge.net <no...@so...> - 2005-08-15 18:10:42
|
Bugs item #1256271, was opened at 2005-08-10 16:45 Message generated for change (Comment added) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: DBAPI Append/Set Object Bug (In-memory & DB related) Initial Comment: If you have two DBAPI objects, such as A and B. If you call A.appendB(B) and then try calling B.getA(), it will fail because the append and set functions don't go to the other object and add them selves to the other object. ---------------------------------------------------------------------- >Comment By: Brandon King (kingb) Date: 2005-08-15 11:10 Message: Logged In: YES user_id=552216 Fixes for bugs 1256258 and 1256271. Memory leak should now be fixed. Ten test cases have be implemented in tests/TestMemLeak.py... All ten pass currently. I tested for slow down in creating and commiting 10,000 objects to a database. It has a 0.2 sec slow down in a 94 sec time frame. The fix includes an object cache which reuses objects which have already been pulled into memory (using weakrefs). Also, there is a new function for DBClass objects called _destroySelf. This function must be called before calling del on an DBClass object. This is only useful when you want to free up some memory when your done with a DBClass object, but the program is going to continue to run. It works by removing all references to the class your trying to remove so that the python ref count will be low enough for garbage collection to free up the memory. Calling del without calling _destroySelf will NOT remove the object from memory. To go back to the memory leaky version check out tag 'pre_aug_2005_mem_patch'. ---------------------------------------------------------------------- Comment By: Brandon King (kingb) Date: 2005-08-10 17:58 Message: Logged In: YES user_id=552216 Dang... as it turns out, this bug applies to objects retrieve from the db, with the only difference that if you call A.getB() and then B.getA(), B is actually returning you a second copy of A from the DB and not giving you the first loaded A. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-08-15 18:09:18
|
Bugs item #1256258, was opened at 2005-08-10 16:19 Message generated for change (Comment added) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256258&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: DBAPI Memory Leak Initial Comment: Pymerase DBAPI has a memory leak where if you have two DBAPI objects (lets say A and B) and you call A.appendB(B) and then call del on B, it won't destory B... This actually shouldn't happen, because if your still holding on to A, then A should still hold on to B. But if you call del on A and B, neither will actually be deleted because this have references eachother and them selves. The solution for is too fold... First using a weakref from each object to itself head in the right direction. Second, a function will need to be implemented such as B._destroySelf() to tell it you want to remove it from memory (which is needed if you commit a large number of Bs and you're try to free up some memory by not holding on to all previously commited B objects). This function _destroySelf() would tell B to go to all associated objects and remove any referrences to itself. Then you would call del B to really remove the object from memory. ---------------------------------------------------------------------- >Comment By: Brandon King (kingb) Date: 2005-08-15 11:09 Message: Logged In: YES user_id=552216 Fixes for bugs 1256258 and 1256271. Memory leak should now be fixed. Ten test cases have be implemented in tests/TestMemLeak.py... All ten pass currently. I tested for slow down in creating and commiting 10,000 objects to a database. It has a 0.2 sec slow down in a 94 sec time frame. The fix includes an object cache which reuses objects which have already been pulled into memory (using weakrefs). Also, there is a new function for DBClass objects called _destroySelf. This function must be called before calling del on an DBClass object. This is only useful when you want to free up some memory when your done with a DBClass object, but the program is going to continue to run. It works by removing all references to the class your trying to remove so that the python ref count will be low enough for garbage collection to free up the memory. Calling del without calling _destroySelf will NOT remove the object from memory. To go back to the memory leaky version check out tag 'pre_aug_2005_mem_patch'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256258&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-08-11 00:59:10
|
Bugs item #1256271, was opened at 2005-08-10 16:45 Message generated for change (Settings changed) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) >Summary: DBAPI Append/Set Object Bug (In-memory & DB related) Initial Comment: If you have two DBAPI objects, such as A and B. If you call A.appendB(B) and then try calling B.getA(), it will fail because the append and set functions don't go to the other object and add them selves to the other object. ---------------------------------------------------------------------- Comment By: Brandon King (kingb) Date: 2005-08-10 17:58 Message: Logged In: YES user_id=552216 Dang... as it turns out, this bug applies to objects retrieve from the db, with the only difference that if you call A.getB() and then B.getA(), B is actually returning you a second copy of A from the DB and not giving you the first loaded A. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-08-11 00:58:43
|
Bugs item #1256271, was opened at 2005-08-10 16:45 Message generated for change (Comment added) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: DBAPI Append/Set Object Bug (In-memory only) Initial Comment: If you have two DBAPI objects, such as A and B. If you call A.appendB(B) and then try calling B.getA(), it will fail because the append and set functions don't go to the other object and add them selves to the other object. ---------------------------------------------------------------------- >Comment By: Brandon King (kingb) Date: 2005-08-10 17:58 Message: Logged In: YES user_id=552216 Dang... as it turns out, this bug applies to objects retrieve from the db, with the only difference that if you call A.getB() and then B.getA(), B is actually returning you a second copy of A from the DB and not giving you the first loaded A. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-08-10 23:45:42
|
Bugs item #1256271, was opened at 2005-08-10 16:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: DBAPI Append/Set Object Bug (In-memory only) Initial Comment: If you have two DBAPI objects, such as A and B. If you call A.appendB(B) and then try calling B.getA(), it will fail because the append and set functions don't go to the other object and add them selves to the other object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256271&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2005-08-10 23:19:08
|
Bugs item #1256258, was opened at 2005-08-10 16:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256258&group_id=63836 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: DBAPI Memory Leak Initial Comment: Pymerase DBAPI has a memory leak where if you have two DBAPI objects (lets say A and B) and you call A.appendB(B) and then call del on B, it won't destory B... This actually shouldn't happen, because if your still holding on to A, then A should still hold on to B. But if you call del on A and B, neither will actually be deleted because this have references eachother and them selves. The solution for is too fold... First using a weakref from each object to itself head in the right direction. Second, a function will need to be implemented such as B._destroySelf() to tell it you want to remove it from memory (which is needed if you commit a large number of Bs and you're try to free up some memory by not holding on to all previously commited B objects). This function _destroySelf() would tell B to go to all associated objects and remove any referrences to itself. Then you would call del B to really remove the object from memory. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=1256258&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2004-07-27 21:34:30
|
Bugs item #999017, was opened at 2004-07-27 14:31 Message generated for change (Comment added) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=999017&group_id=63836 Category: Output: CreateDBAPI Group: v0.2 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: SELECT * FROM table WHERE table_pk = None Error Initial Comment: When ever an sql statement like 'SELECT * FROM table WHERE table_pk = None' shows up, it throws an annoying error message, it should not even attempt to run the sql statement, and instead return an empty list. ---------------------------------------------------------------------- >Comment By: Brandon King (kingb) Date: 2004-07-27 14:34 Message: Logged In: YES user_id=552216 Fixed with dbAPI.py version 1.42. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=999017&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2004-07-27 21:31:32
|
Bugs item #999017, was opened at 2004-07-27 14:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=999017&group_id=63836 Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 9 Submitted By: Brandon King (kingb) Assigned to: Brandon King (kingb) Summary: SELECT * FROM table WHERE table_pk = None Error Initial Comment: When ever an sql statement like 'SELECT * FROM table WHERE table_pk = None' shows up, it throws an annoying error message, it should not even attempt to run the sql statement, and instead return an empty list. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=999017&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2004-07-12 22:08:43
|
Feature Requests item #989780, was opened at 2004-07-12 15:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=989780&group_id=63836 Category: Output: CreateDBAPI Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: None to null mapping Initial Comment: We would like pymerase to add code to handle saving a python object's fields having value None as columns in an SQL table using the value null. Likewise, on object retrieval, columns with value null should produce object fields with value None. Thanks! You Pymerase developers are GREAT! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505348&aid=989780&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2004-05-28 00:36:45
|
Bugs item #961879, was opened at 2004-05-27 14:51 Message generated for change (Comment added) made by kingb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=961879&group_id=63836 Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 8 Submitted By: Brandon King (kingb) Assigned to: Nobody/Anonymous (nobody) Summary: Retrieving associated object from a new, uncommited object. Initial Comment: Retrieving an associated object from a new, uncommited object spews warnings, like the following: SELECT * FROM "attribute_value" WHERE "gene_fk" = None ERROR: column "none" does not exist It's trying to do an SQL query based on the objects primary key, which hasn't been created yet as it has not been committed. If this object had been commited, but didn't have an associated objects, it would return an empty list. I'd suggest that a new, uncommited object either return an empty list or throw an error of some sort. Example of problem: > myObj = dbs.MyObj() > myObj.getAssociatedObjects() SELECT * FROM "associated_object" WHERE "my_object_fk" = None ERROR: column "none" does not exist ---------------------------------------------------------------------- >Comment By: Brandon King (kingb) Date: 2004-05-27 17:36 Message: Logged In: YES user_id=552216 Okay, so a new uncommited object does return an empty list, like I was expecting, but I don't think the warning message should be shown in this situation as the SQL probably shouldn't even be executed when PK = None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=961879&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2004-05-27 21:51:26
|
Bugs item #961879, was opened at 2004-05-27 14:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=961879&group_id=63836 Category: Output: CreateDBAPI Group: v0.2 Status: Open Resolution: None Priority: 8 Submitted By: Brandon King (kingb) Assigned to: Nobody/Anonymous (nobody) Summary: Retrieving associated object from a new, uncommited object. Initial Comment: Retrieving an associated object from a new, uncommited object spews warnings, like the following: SELECT * FROM "attribute_value" WHERE "gene_fk" = None ERROR: column "none" does not exist It's trying to do an SQL query based on the objects primary key, which hasn't been created yet as it has not been committed. If this object had been commited, but didn't have an associated objects, it would return an empty list. I'd suggest that a new, uncommited object either return an empty list or throw an error of some sort. Example of problem: > myObj = dbs.MyObj() > myObj.getAssociatedObjects() SELECT * FROM "associated_object" WHERE "my_object_fk" = None ERROR: column "none" does not exist ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=961879&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2004-05-21 01:05:35
|
Bugs item #957767, was opened at 2004-05-20 17:55 Message generated for change (Comment added) made by detrout You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=957767&group_id=63836 Category: Output: CreateDBAPI Group: None >Status: Closed Resolution: None Priority: 7 Submitted By: Brandon King (kingb) Assigned to: Diane Trout (detrout) Summary: Refresh does not refresh association links Initial Comment: Refresh does not refresh association links... This causes problems if an association gets via SQL or some other method and you want to refresh your dbObj in ipython. ---------------------------------------------------------------------- >Comment By: Diane Trout (detrout) Date: 2004-05-20 18:05 Message: Logged In: YES user_id=122283 fixed... though I really should write a unit test for it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=957767&group_id=63836 |
|
From: SourceForge.net <no...@so...> - 2004-05-21 00:55:34
|
Bugs item #957767, was opened at 2004-05-20 17:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=957767&group_id=63836 Category: Output: CreateDBAPI Group: None Status: Open Resolution: None Priority: 7 Submitted By: Brandon King (kingb) Assigned to: Diane Trout (detrout) Summary: Refresh does not refresh association links Initial Comment: Refresh does not refresh association links... This causes problems if an association gets via SQL or some other method and you want to refresh your dbObj in ipython. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=505345&aid=957767&group_id=63836 |
