sqlobject-cvs Mailing List for SQLObject (Page 133)
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
Menu
▾
▴
sqlobject-cvs — CVS notification
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(9) |
Apr
(74) |
May
(29) |
Jun
(16) |
Jul
(28) |
Aug
(10) |
Sep
(57) |
Oct
(9) |
Nov
(29) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(14) |
Mar
(6) |
Apr
(3) |
May
(12) |
Jun
(34) |
Jul
(9) |
Aug
(29) |
Sep
(22) |
Oct
(2) |
Nov
(15) |
Dec
(52) |
| 2005 |
Jan
(47) |
Feb
(78) |
Mar
(14) |
Apr
(35) |
May
(33) |
Jun
(16) |
Jul
(26) |
Aug
(63) |
Sep
(40) |
Oct
(96) |
Nov
(96) |
Dec
(123) |
| 2006 |
Jan
(159) |
Feb
(144) |
Mar
(64) |
Apr
(31) |
May
(88) |
Jun
(48) |
Jul
(16) |
Aug
(64) |
Sep
(87) |
Oct
(92) |
Nov
(56) |
Dec
(76) |
| 2007 |
Jan
(94) |
Feb
(103) |
Mar
(126) |
Apr
(123) |
May
(85) |
Jun
(11) |
Jul
(130) |
Aug
(47) |
Sep
(65) |
Oct
(70) |
Nov
(12) |
Dec
(11) |
| 2008 |
Jan
(30) |
Feb
(55) |
Mar
(88) |
Apr
(20) |
May
(50) |
Jun
|
Jul
(38) |
Aug
(1) |
Sep
(9) |
Oct
(5) |
Nov
(6) |
Dec
(39) |
| 2009 |
Jan
(8) |
Feb
(16) |
Mar
(3) |
Apr
(33) |
May
(44) |
Jun
(1) |
Jul
(10) |
Aug
(33) |
Sep
(74) |
Oct
(22) |
Nov
|
Dec
(15) |
| 2010 |
Jan
(28) |
Feb
(22) |
Mar
(46) |
Apr
(29) |
May
(1) |
Jun
(1) |
Jul
(27) |
Aug
(8) |
Sep
(5) |
Oct
(33) |
Nov
(24) |
Dec
(41) |
| 2011 |
Jan
(4) |
Feb
(12) |
Mar
(35) |
Apr
(29) |
May
(19) |
Jun
(16) |
Jul
(32) |
Aug
(25) |
Sep
(5) |
Oct
(11) |
Nov
(21) |
Dec
(12) |
| 2012 |
Jan
(3) |
Feb
(4) |
Mar
(20) |
Apr
(4) |
May
(25) |
Jun
(13) |
Jul
|
Aug
|
Sep
(2) |
Oct
(25) |
Nov
(9) |
Dec
(1) |
| 2013 |
Jan
(6) |
Feb
(8) |
Mar
|
Apr
(10) |
May
(31) |
Jun
(7) |
Jul
(18) |
Aug
(33) |
Sep
(4) |
Oct
(16) |
Nov
|
Dec
(27) |
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
(11) |
May
(39) |
Jun
(8) |
Jul
(11) |
Aug
(4) |
Sep
|
Oct
(27) |
Nov
|
Dec
(71) |
| 2015 |
Jan
(17) |
Feb
(47) |
Mar
(33) |
Apr
|
May
|
Jun
(9) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(8) |
| 2016 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
|
May
(12) |
Jun
(7) |
Jul
(9) |
Aug
(31) |
Sep
(8) |
Oct
(3) |
Nov
(15) |
Dec
(1) |
| 2017 |
Jan
(13) |
Feb
(7) |
Mar
(14) |
Apr
(8) |
May
(10) |
Jun
(4) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
(8) |
Nov
(4) |
Dec
(5) |
| 2018 |
Jan
(2) |
Feb
(8) |
Mar
|
Apr
(4) |
May
|
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2019 |
Jan
(1) |
Feb
(16) |
Mar
(1) |
Apr
(3) |
May
(5) |
Jun
(1) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
(2) |
| 2021 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
| 2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(3) |
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
|
| 2024 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(9) |
| 2025 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
|
From: SourceForge.net <no...@so...> - 2006-03-26 21:14:05
|
Bugs item #1458595, was opened at 2006-03-25 18:52 Message generated for change (Comment added) made by cpisto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338 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: None Group: SQLObject from repository Status: Open Resolution: None Priority: 5 Submitted By: Cody Pisto (cpisto) Assigned to: Nobody/Anonymous (nobody) Summary: destroySelf in transaction causes lockup Initial Comment: Calling destroySelf() on an sqlobject acquired in the same explicit transaction (using conn.transaction()...) causes the entire python interpreter to lockup if the sqlobject schema in question has any SQLRelatedJoin's and the accompaying remove[JoinCol]() function is called in the transaction before destroySelf(). PDB stepping seems to be of no use, the interpreter locks up on line 306 of dbconnection.py "return cursor.execute(query)" The same sequence of calls works without problems outside a transaction. Version details: Python 2.4.2 PostgreSQL 8.1.2 (via psycopg2 2.0b8 or psycopg 1.1.21) SQLObject 0.8dev r1668 and r1615 ---------------------------------------------------------------------- >Comment By: Cody Pisto (cpisto) Date: 2006-03-26 14:14 Message: Logged In: YES user_id=118227 OK, after further investigation, It seems that for some reason a second database connection is being created during the lifetime of the transaction (by one of the SQLObjects instantiated inside doInTransaction), so a deadlock is occuring while this second connection waits for a commit on the first connection, I am still investating why this second connection is being created... ---------------------------------------------------------------------- Comment By: Cody Pisto (cpisto) Date: 2006-03-25 21:27 Message: Logged In: YES user_id=118227 The following link seems to reference the exact same problem, only on a slightly older version of sqlobject, and using mysql. http://www.mail-archive.com/sql...@li.../msg00226.html After contacting the poster, reverting to a much older version of sqlobject (r1547) seems to work around the issue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-26 04:27:24
|
Bugs item #1458595, was opened at 2006-03-25 18:52 Message generated for change (Comment added) made by cpisto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338 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: None Group: SQLObject from repository Status: Open Resolution: None Priority: 5 Submitted By: Cody Pisto (cpisto) Assigned to: Nobody/Anonymous (nobody) Summary: destroySelf in transaction causes lockup Initial Comment: Calling destroySelf() on an sqlobject acquired in the same explicit transaction (using conn.transaction()...) causes the entire python interpreter to lockup if the sqlobject schema in question has any SQLRelatedJoin's and the accompaying remove[JoinCol]() function is called in the transaction before destroySelf(). PDB stepping seems to be of no use, the interpreter locks up on line 306 of dbconnection.py "return cursor.execute(query)" The same sequence of calls works without problems outside a transaction. Version details: Python 2.4.2 PostgreSQL 8.1.2 (via psycopg2 2.0b8 or psycopg 1.1.21) SQLObject 0.8dev r1668 and r1615 ---------------------------------------------------------------------- >Comment By: Cody Pisto (cpisto) Date: 2006-03-25 21:27 Message: Logged In: YES user_id=118227 The following link seems to reference the exact same problem, only on a slightly older version of sqlobject, and using mysql. http://www.mail-archive.com/sql...@li.../msg00226.html After contacting the poster, reverting to a much older version of sqlobject (r1547) seems to work around the issue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-26 01:53:01
|
Bugs item #1458595, was opened at 2006-03-25 18:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338 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: None Group: SQLObject from repository Status: Open Resolution: None Priority: 5 Submitted By: Cody Pisto (cpisto) Assigned to: Nobody/Anonymous (nobody) Summary: destroySelf in transaction causes lockup Initial Comment: Calling destroySelf() on an sqlobject acquired in the same explicit transaction (using conn.transaction()...) causes the entire python interpreter to lockup if the sqlobject schema in question has any SQLRelatedJoin's and the accompaying remove[JoinCol]() function is called in the transaction before destroySelf(). PDB stepping seems to be of no use, the interpreter locks up on line 306 of dbconnection.py "return cursor.execute(query)" The same sequence of calls works without problems outside a transaction. Version details: Python 2.4.2 PostgreSQL 8.1.2 (via psycopg2 2.0b8 or psycopg 1.1.21) SQLObject 0.8dev r1668 and r1615 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1458595&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-25 18:08:33
|
Patches item #1458380, was opened at 2006-03-25 19:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1458380&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dennis Brakhane (dennis) Assigned to: Nobody/Anonymous (nobody) Summary: Let admin create tables with no foreign keys first Initial Comment: Suppose I have the following model: class A(SQLObject): foo = StringCol() b = ForeignKey("B") class B(SQLObject): bar = StringCol() If I now let sqlobject-admin create the tables for me, the order in with these are created is not defined. If table A is created before table B, PostgreSQL will fail: CREATE TABLE a ( id SERIAL PRIMARY KEY, foo TEXT, b_id INT, CONSTRAINT b_id_exists FOREIGN KEY (b_id) REFERENCES b (id) ) Fails with "Relation >b< does not exist" So, I've patched manager/command.py to create tables in the order of classes with fewest foreign keys created first. This might not catch all cases, but it "works for me(TM)" Patch is attached ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1458380&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 21:36:32
|
Bugs item #1456453, was opened at 2006-03-22 16:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1456453&group_id=74338 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: General Group: SQLObject release (specify) Status: Open Resolution: None Priority: 5 Submitted By: Andrew Barilla (abarilla) Assigned to: Nobody/Anonymous (nobody) Summary: count(1) is more effecient than count(*) Initial Comment: Instead of COUNT(*), COUNT(1) is more effecient. I'm not sure if this is compatible with all of the DBMSes but I know it works with MSSQL and Postgresql. This is because the database engine/server does not need to pull back all of the database fields. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1456453&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 10:04:04
|
Patches item #1450591, was opened at 2006-03-15 21:24 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450591&group_id=74338 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: None Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for TINYINT, BIGINT, etc. Initial Comment: Storage size should be considered when assigning column types. If an int value is never going to be larger than one byte, it should not be assigned to an INT column type, instead TINYINT should be used. The patch adds support for TINYINT, SMALLINT, MEDIUMINT, and BIGINT columns (these are all supported under MySQL, other support is unknown) by adding TinyIntCol, SmallIntCol, MediumIntCol, and BigIntCol classes. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 13:03 Message: Logged In: YES user_id=4799 Please add documentation and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450591&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 10:03:16
|
Patches item #1450587, was opened at 2006-03-15 21:20 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450587&group_id=74338 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: None Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for MySQL ENGINE specification Initial Comment: MySQL supports several different database engine types, each having its own advantage and drawbacks, with two of the most prevalent being InnoDB (support for transactions and indices) and MyISAM. The engine type can be explicitly specified at the end of a CREATE TABLE. E.g., CREATE TABLE test ( id INT PRIMARY KEY AUTO_INCREMENT, value INT ) ENGINE=InnoDB; The patch adds an engine keyword into the SQLObject that can be used to append the ENGINE specification to every table creation. Usage: SQLObject.engine = "InnoDB" ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 13:03 Message: Logged In: YES user_id=4799 Please add documentation and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450587&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 10:01:53
|
Patches item #1450584, was opened at 2006-03-15 21:13 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450584&group_id=74338 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: None Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Support for DEFAULT SQL attribute Initial Comment: The built-in SQLObject default keyword only works within the SQLObject framework. I.e., SQLObject inserts the value before performing and INSERT. For consistancy, it would be best if this was handled by the database. The patch provides adds a defaultSQL keyword to col defines, which will add the DEFAULT %s value into a CREATE TABLE statement. Also, it will allow all columns declared with the defaultSQL to pass cleanly through the SQLObject interface without being explicitly defined. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 13:01 Message: Logged In: YES user_id=4799 Please add documentation and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450584&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 10:00:20
|
Patches item #1450581, was opened at 2006-03-15 21:08 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450581&group_id=74338 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: None Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No support for MySQL SET type Initial Comment: I am not certain whether or not the other databases other than MySQL have a SET type, but it does provide the ability to choose multiple values from your standard ENUM-like choices. The patch adds a SetCol object with a setValues keyword, used to specify the values in the form of a tuple. Values are converted to the comma-delimited SQL string for SQL queries, and the return values are converted back into a tuple. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 13:00 Message: Logged In: YES user_id=4799 Please add documentation and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450581&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 09:58:58
|
Patches item #1450576, was opened at 2006-03-15 21:03 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450576&group_id=74338 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: None Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No support for INT type attributes: UNSIGNED, etc. Initial Comment: Patch attached to add keyword support for UNSIGNED, ZEROFILL, and length specifiers for the IntCol class. Most of these functions can be done with checks and formatting from the python side, but I feel they should be declared in the underlying DB structure as well. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 12:58 Message: Logged In: YES user_id=4799 Please add documentation and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450576&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 09:57:38
|
Patches item #1450570, was opened at 2006-03-15 20:59 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450570&group_id=74338 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: None Group: None Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No support for MySQL TIMESTAMP type Initial Comment: SQLObject does support a DatetimeCol for MySQL, but does not have support for the TIMESTAMP column type. Databases will usually support either one or the other (or neither and a CHECK type), but MySQL uses both DATETIME and TIMESTAMP and they each perform a different role. For example, if you want to record the time a row was initially created: CREATE TABLE test ( id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, value INT, time_added TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); The CURRENT_TIMESTAMP and NOW() functions are not supported with the DATETIME column. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 12:57 Message: Logged In: YES user_id=4799 Please add documentation and tests. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450570&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 09:57:33
|
Patches item #1450564, was opened at 2006-03-15 20:52 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450564&group_id=74338 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: None Group: None >Status: Open >Resolution: Invalid Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Limit keyword does not with orderBy Initial Comment: When performing a select query over a table, the limit keyword will not be used if orderBy is specified. For example, class Test(SQLObject): total IntCol(notNull=True) # create SQL connection and stuff ... res = Test.select(orderBy='total', limit=10) The results will contain every row from Test, since the resultant SQL query is similar to "SELECT id, total FROM test ORDER BY total" No LIMIT attribute is ever specified. Looking at the code, this is because limit will only work when used with the start or end keyword. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 12:57 Message: Logged In: YES user_id=4799 Please add documentation and tests. ---------------------------------------------------------------------- Comment By: Oleg Broytmann (phd) Date: 2006-03-21 12:53 Message: Logged In: YES user_id=4799 The query should be res = Test.select(orderBy='total')[:10] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450564&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 09:53:27
|
Patches item #1450564, was opened at 2006-03-15 20:52 Message generated for change (Comment added) made by phd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450564&group_id=74338 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: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Limit keyword does not with orderBy Initial Comment: When performing a select query over a table, the limit keyword will not be used if orderBy is specified. For example, class Test(SQLObject): total IntCol(notNull=True) # create SQL connection and stuff ... res = Test.select(orderBy='total', limit=10) The results will contain every row from Test, since the resultant SQL query is similar to "SELECT id, total FROM test ORDER BY total" No LIMIT attribute is ever specified. Looking at the code, this is because limit will only work when used with the start or end keyword. ---------------------------------------------------------------------- >Comment By: Oleg Broytmann (phd) Date: 2006-03-21 12:53 Message: Logged In: YES user_id=4799 The query should be res = Test.select(orderBy='total')[:10] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450564&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-21 09:47:44
|
Bugs item #1455251, was opened at 2006-03-21 12:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1455251&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Oleg Broytmann (phd) Assigned to: Nobody/Anonymous (nobody) Summary: dbConnection.query() opens another connection Initial Comment: DBConnection often uses self.query() to run additional queries. That's acceptable for DDL queries (CREATE/DROP) but is very bad for DML queries (SELECT/INSERT/UPDATE/DELETE) because the new query is executed in a different connection, outside of the current transaction. Even worse, for row.destroySelf() SQLite often fails with the error "Database is locked". DBConnection mustn't use self.query(); the query must be run via the current low-level (raw) connection. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1455251&group_id=74338 |
|
From: <sub...@co...> - 2006-03-21 09:10:14
|
Author: phd
Date: 2006-03-21 02:10:09 -0700 (Tue, 21 Mar 2006)
New Revision: 1670
Modified:
home/phd/SQLObject/paramstyles/sqlobject/mysql/mysqlconnection.py
Log:
Merged patches from the revisions 1667:1669 from the trunk: a patch by David Faure <df...@kl...> to use DESCRIBE instead of SHOW TABLES.
Modified: home/phd/SQLObject/paramstyles/sqlobject/mysql/mysqlconnection.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/mysql/mysqlconnection.py 2006-03-21 09:09:14 UTC (rev 1669)
+++ home/phd/SQLObject/paramstyles/sqlobject/mysql/mysqlconnection.py 2006-03-21 09:10:09 UTC (rev 1670)
@@ -116,10 +116,16 @@
return 'INT NOT NULL'
def tableExists(self, tableName):
- for (table,) in self.queryAll('SHOW TABLES'):
- if table.lower() == tableName.lower():
- return True
- return False
+ try:
+ # Use DESCRIBE instead of SHOW TABLES because SHOW TABLES
+ # assumes there is a default database selected
+ # which is not always True (for an embedded application, e.g.)
+ self.query('DESCRIBE %s' % (tableName))
+ return True
+ except MySQLdb.ProgrammingError, e:
+ if e.args[0] == 1146: # ER_NO_SUCH_TABLE
+ return False
+ raise
def addColumn(self, tableName, column):
self.query('ALTER TABLE %s ADD COLUMN %s' %
|
|
From: <sub...@co...> - 2006-03-21 09:09:22
|
Author: phd
Date: 2006-03-21 02:09:14 -0700 (Tue, 21 Mar 2006)
New Revision: 1669
Modified:
SQLObject/branches/0.7-bugfix/sqlobject/mysql/mysqlconnection.py
Log:
Merged a patch by David Faure <df...@kl...>
to use DESCRIBE instead of SHOW TABLES.
Modified: SQLObject/branches/0.7-bugfix/sqlobject/mysql/mysqlconnection.py
===================================================================
--- SQLObject/branches/0.7-bugfix/sqlobject/mysql/mysqlconnection.py 2006-03-21 09:08:36 UTC (rev 1668)
+++ SQLObject/branches/0.7-bugfix/sqlobject/mysql/mysqlconnection.py 2006-03-21 09:09:14 UTC (rev 1669)
@@ -105,10 +105,16 @@
return 'INT NOT NULL'
def tableExists(self, tableName):
- for (table,) in self.queryAll('SHOW TABLES'):
- if table.lower() == tableName.lower():
- return True
- return False
+ try:
+ # Use DESCRIBE instead of SHOW TABLES because SHOW TABLES
+ # assumes there is a default database selected
+ # which is not always True (for an embedded application, e.g.)
+ self.query('DESCRIBE %s' % (tableName))
+ return True
+ except MySQLdb.ProgrammingError, e:
+ if e.args[0] == 1146: # ER_NO_SUCH_TABLE
+ return False
+ raise
def addColumn(self, tableName, column):
self.query('ALTER TABLE %s ADD COLUMN %s' %
|
|
From: <sub...@co...> - 2006-03-21 09:08:44
|
Author: phd
Date: 2006-03-21 02:08:36 -0700 (Tue, 21 Mar 2006)
New Revision: 1668
Modified:
SQLObject/trunk/sqlobject/mysql/mysqlconnection.py
Log:
A patch by David Faure <df...@kl...> to use DESCRIBE
instead of SHOW TABLES.
Modified: SQLObject/trunk/sqlobject/mysql/mysqlconnection.py
===================================================================
--- SQLObject/trunk/sqlobject/mysql/mysqlconnection.py 2006-03-20 23:15:26 UTC (rev 1667)
+++ SQLObject/trunk/sqlobject/mysql/mysqlconnection.py 2006-03-21 09:08:36 UTC (rev 1668)
@@ -116,10 +116,16 @@
return 'INT NOT NULL'
def tableExists(self, tableName):
- for (table,) in self.queryAll('SHOW TABLES'):
- if table.lower() == tableName.lower():
- return True
- return False
+ try:
+ # Use DESCRIBE instead of SHOW TABLES because SHOW TABLES
+ # assumes there is a default database selected
+ # which is not always True (for an embedded application, e.g.)
+ self.query('DESCRIBE %s' % (tableName))
+ return True
+ except MySQLdb.ProgrammingError, e:
+ if e.args[0] == 1146: # ER_NO_SUCH_TABLE
+ return False
+ raise
def addColumn(self, tableName, column):
self.query('ALTER TABLE %s ADD COLUMN %s' %
|
|
From: SourceForge.net <no...@so...> - 2006-03-15 18:24:22
|
Patches item #1450591, was opened at 2006-03-15 10:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450591&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for TINYINT, BIGINT, etc. Initial Comment: Storage size should be considered when assigning column types. If an int value is never going to be larger than one byte, it should not be assigned to an INT column type, instead TINYINT should be used. The patch adds support for TINYINT, SMALLINT, MEDIUMINT, and BIGINT columns (these are all supported under MySQL, other support is unknown) by adding TinyIntCol, SmallIntCol, MediumIntCol, and BigIntCol classes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450591&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 18:20:16
|
Patches item #1450587, was opened at 2006-03-15 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450587&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for MySQL ENGINE specification Initial Comment: MySQL supports several different database engine types, each having its own advantage and drawbacks, with two of the most prevalent being InnoDB (support for transactions and indices) and MyISAM. The engine type can be explicitly specified at the end of a CREATE TABLE. E.g., CREATE TABLE test ( id INT PRIMARY KEY AUTO_INCREMENT, value INT ) ENGINE=InnoDB; The patch adds an engine keyword into the SQLObject that can be used to append the ENGINE specification to every table creation. Usage: SQLObject.engine = "InnoDB" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450587&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 18:13:30
|
Patches item #1450584, was opened at 2006-03-15 10:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450584&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Support for DEFAULT SQL attribute Initial Comment: The built-in SQLObject default keyword only works within the SQLObject framework. I.e., SQLObject inserts the value before performing and INSERT. For consistancy, it would be best if this was handled by the database. The patch provides adds a defaultSQL keyword to col defines, which will add the DEFAULT %s value into a CREATE TABLE statement. Also, it will allow all columns declared with the defaultSQL to pass cleanly through the SQLObject interface without being explicitly defined. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450584&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 18:08:39
|
Patches item #1450581, was opened at 2006-03-15 10:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450581&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No support for MySQL SET type Initial Comment: I am not certain whether or not the other databases other than MySQL have a SET type, but it does provide the ability to choose multiple values from your standard ENUM-like choices. The patch adds a SetCol object with a setValues keyword, used to specify the values in the form of a tuple. Values are converted to the comma-delimited SQL string for SQL queries, and the return values are converted back into a tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450581&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 18:03:46
|
Patches item #1450576, was opened at 2006-03-15 10:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450576&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No support for INT type attributes: UNSIGNED, etc. Initial Comment: Patch attached to add keyword support for UNSIGNED, ZEROFILL, and length specifiers for the IntCol class. Most of these functions can be done with checks and formatting from the python side, but I feel they should be declared in the underlying DB structure as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450576&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 17:59:10
|
Patches item #1450570, was opened at 2006-03-15 09:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450570&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: No support for MySQL TIMESTAMP type Initial Comment: SQLObject does support a DatetimeCol for MySQL, but does not have support for the TIMESTAMP column type. Databases will usually support either one or the other (or neither and a CHECK type), but MySQL uses both DATETIME and TIMESTAMP and they each perform a different role. For example, if you want to record the time a row was initially created: CREATE TABLE test ( id INT NOT NULL PRIMARY KEY AUTO_INCREMENT, value INT, time_added TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); The CURRENT_TIMESTAMP and NOW() functions are not supported with the DATETIME column. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450570&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 17:58:20
|
Patches item #1450568, was opened at 2006-03-15 18:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450568&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Davide Alberani (alberanid) Assigned to: Nobody/Anonymous (nobody) Summary: faster sqlbuilder.Insert Initial Comment: In the attachment, a very simple patch to improve performances (about 12 times faster, with a list of ~20000 items, tested with python2.3) of the sqlbuilder.Insert class, when a very long valueList list is provided. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450568&group_id=74338 |
|
From: SourceForge.net <no...@so...> - 2006-03-15 17:52:36
|
Patches item #1450564, was opened at 2006-03-15 09:52 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450564&group_id=74338 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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Limit keyword does not with orderBy Initial Comment: When performing a select query over a table, the limit keyword will not be used if orderBy is specified. For example, class Test(SQLObject): total IntCol(notNull=True) # create SQL connection and stuff ... res = Test.select(orderBy='total', limit=10) The results will contain every row from Test, since the resultant SQL query is similar to "SELECT id, total FROM test ORDER BY total" No LIMIT attribute is ever specified. Looking at the code, this is because limit will only work when used with the start or end keyword. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1450564&group_id=74338 |
89 messages has been excluded from this view by a project administrator.
