sqlobject-cvs — CVS notification

[SQL-CVS] [ sqlobject-Patches-1423272 ] Events RowCreateSignal not really useful, added post-create

[SourceForge.net <no...@so...>]

Patches item #1423272, was opened at 2006-02-03 11:00
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=1423272&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: Rick Richardson (rovar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Events RowCreateSignal not really useful, added post-create

Initial Comment:
The RoWCreateSignal suffers from two drawbacks based on
the fact that it fires before a row is created. 

First, it can't give a reference to the created row
(which is what i would picture a large percentage of
users would want it for) 

Secondly, it fires whether the row was successfully
created or not. 

In the case of the auditing system that i'm writing. I
desperately need these two features. So I added a
RowCreatedSignal and then added the code to invoke it
in the _SO_finishCreate function and it passes the
created ID and the class to the callback. 

I've tested it. seems to work alright. Attached is the
patch if you wish to use it. 


Rick

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1423272&group_id=74338

[SQL-CVS] r1559 - SQLObject/docs

[<sub...@co...>]

Author: ianb
Date: 2006-02-02 15:43:28 -0700 (Thu, 02 Feb 2006)
New Revision: 1559

Modified:
   SQLObject/docs/SQLObject.comments.txt
Log:
in page: http://pythonpaste.org/SQLObject.html
by: Big <Man>
Add comment

Modified: SQLObject/docs/SQLObject.comments.txt
===================================================================
--- SQLObject/docs/SQLObject.comments.txt	2006-02-02 22:28:51 UTC (rev 1558)
+++ SQLObject/docs/SQLObject.comments.txt	2006-02-02 22:43:28 UTC (rev 1559)
@@ -24,9 +24,7 @@
 ip: 208.255.226.178
 username: Mike Kent
 
-So if you declare a column as an alternateID, unique is implied, and we don't need to explicitly declare it?
-
-shouldn't this be protected???
+So if you declare a column as an alternateID, unique is implied, and we don't need to explicitly declare it?shouldn't this be protected???
 ==== $(orderby) +
 ----------------------------------------
 date: 2005-12-08T10:47:35
@@ -45,3 +43,12 @@
 username: Joe
 
 Think about breaking these SELECT statements onto several lines.  They're busting out of the page design now.
+==== $(col-class-specifying-columns)  c ++ c +++++ c +
+----------------------------------------
+date: 2006-02-02T15:43:28
+email: Man
+id: 11
+ip: 192.100.104.28
+username: Big
+
+StringCol's that are alternateID's must have a length property if you use them in MySQL.

[SQL-CVS] r1558 - SQLObject/docs

[<sub...@co...>]

Author: ianb
Date: 2006-02-02 15:28:51 -0700 (Thu, 02 Feb 2006)
New Revision: 1558

Modified:
   SQLObject/docs/SQLObject.comments.txt
Log:
in page: http://pythonpaste.org/SQLObject.html

Modified: SQLObject/docs/SQLObject.comments.txt
===================================================================
--- SQLObject/docs/SQLObject.comments.txt	2006-02-01 16:23:11 UTC (rev 1557)
+++ SQLObject/docs/SQLObject.comments.txt	2006-02-02 22:28:51 UTC (rev 1558)
@@ -25,6 +25,8 @@
 username: Mike Kent
 
 So if you declare a column as an alternateID, unique is implied, and we don't need to explicitly declare it?
+
+shouldn't this be protected???
 ==== $(orderby) +
 ----------------------------------------
 date: 2005-12-08T10:47:35

[SQL-CVS] [ sqlobject-Patches-1417936 ] user unfriendly error message in manager.command

[SourceForge.net <no...@so...>]

Patches item #1417936, was opened at 2006-01-29 14:45
Message generated for change (Comment added) made by mfi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417936&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: Maxim F. Ischenko (mfi)
Assigned to: Nobody/Anonymous (nobody)
Summary: user unfriendly error message in manager.command

Initial Comment:
Description and patch (just a few lines) available at
http://trac.turbogears.org/turbogears/ticket/459#preview

----------------------------------------------------------------------

>Comment By: Maxim F. Ischenko (mfi)
Date: 2006-02-02 10:28

Message:
Logged In: YES 
user_id=113894

Would you mind to write whether you're going to accept or
decline the patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417936&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1422132 ] [patch] selectBy(nonexistantcolumn=foo) passes silently

[SourceForge.net <no...@so...>]

Patches item #1422132, was opened at 2006-02-02 13:44
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=1422132&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: Stephen Thorne (jerub)
Assigned to: Nobody/Anonymous (nobody)
Summary: [patch] selectBy(nonexistantcolumn=foo) passes silently

Initial Comment:
When doing a query on a table, for instance:

Foo.selectBy(food="bar")

where 'food' is a typo, and 'foo' is the correct column
name, no error will occur, and this is equivilnet to:

Foo.select()

Attached is a patch to both dbconnection.py and
tests/test_select.py, adding an exception to the code
for the case where unexpected kwargs are passed, and a
test for that behaviour.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1422132&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1421647 ] sqlobject-manager sql (show create-table commands) semicolon

[SourceForge.net <no...@so...>]

Bugs item #1421647, was opened at 2006-02-01 11:59
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=1421647&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 from repository
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Holth (joeforker)
Assigned to: Nobody/Anonymous (nobody)
Summary: sqlobject-manager sql (show create-table commands) semicolon

Initial Comment:
Hi, I'm playing with turboblog
(http://svn.turboblog.python-hosting.com/turboblog)
with postgresql as the database. sqlobject-manager will
print my database CREATE TABLE () but it's severely
lacking in ; . This would be okay except for some
reason it does not create the tables correctly in the
normal way.

So I must print the CREATE TABLE commands, add the
necessary semicolons, and run it through psql.

Notice the linkage tables are created with the same
function call as the main table. Then the 'sql' command
of sqlobject-admin (sqlobject/manager/command.py line
495) adds one semicolon for the group.

CREATE TABLE tg_group (
    id SERIAL PRIMARY KEY,
    child_name VARCHAR(255),
    group_id VARCHAR(16) NOT NULL UNIQUE,
    display_name VARCHAR(255),
    created TIMESTAMP
)
CREATE TABLE tg_user_group (
group_id INT NOT NULL,
user_id INT NOT NULL
)
CREATE TABLE tg_group_permission (
group_id INT NOT NULL,
permission_id INT NOT NULL
);

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1421647&group_id=74338

[SQL-CVS] [ sqlobject-Bugs-1421633 ] template0 versus template1

[SourceForge.net <no...@so...>]

Bugs item #1421633, was opened at 2006-02-01 08:40
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=1421633&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: Postgres
Group: SQLObject from repository
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: template0 versus template1

Initial Comment:
There's a comment in SQLObject from the repository
about what the difference between template0 and
template1 is. It should not specify the template at
all, it should just use the default one when it runs
CREATE DATABASE.

It is also very naughty to create the database from
template0. First, the postgresql 8.1 docs say template0
is called postgres instead. Second, template1 is the
place for database features the user intends to put in
all new databases (for me, it's pl/sql and postgis
geographic types).

Just connect to template1 or don't specify a database
name to connect to and 'CREATE DATABASE db_name'. It
works fine.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540672&aid=1421633&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1421263 ] configurable client character set (encoding) for MySQL

[SourceForge.net <no...@so...>]

Patches item #1421263, was opened at 2006-02-01 10:39
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=1421263&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: Maxim F. Ischenko (mfi)
Assigned to: Nobody/Anonymous (nobody)
Summary: configurable client character set (encoding) for MySQL

Initial Comment:
This patch adds 'client_encoding' parameter to
MySQLConnection class which is used to configure MySQL
connection with "SET NAMES" command. This is the only
way for MySQL 4.x on Windows to configure client
encoding and is crucial for non-ascii databases.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1421263&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1417339 ] debug SQL queries recorded through logging module

[SourceForge.net <no...@so...>]

Patches item #1417339, was opened at 2006-01-28 13:51
Message generated for change (Comment added) made by mfi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&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: Maxim F. Ischenko (mfi)
Assigned to: Nobody/Anonymous (nobody)
Summary: debug SQL queries recorded through logging module

Initial Comment:
The patch adds support for standard logging module for
DBConnection classes which is crucial for using
sqlobject in cgi scripts -- you can't use STDOUT
because it is sent to the browser.

Logging is activated if user specifies logger key, the
key also serves as a logger name to be used.

This is a duplicate of the previous ticket, only with a
file attacheed (hope so).

----------------------------------------------------------------------

>Comment By: Maxim F. Ischenko (mfi)
Date: 2006-02-01 10:36

Message:
Logged In: YES 
user_id=113894

Here is new patch

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 18:57

Message:
Logged In: YES 
user_id=4799

Aha, that's better. Can you aslo add a test that sets up a
logger (logging to a stderr or a separate file) and a patch
for documentation (describe the "logger" keyword in a DB URI)?

----------------------------------------------------------------------

Comment By: Maxim F. Ischenko (mfi)
Date: 2006-01-31 18:04

Message:
Logged In: YES 
user_id=113894

Oleg, I was considered checking for logging module but then
decided that if a person specifies 'logger' parameter to db
connection then he should know what he's doing.

If you insist, I can add some way of handling this error but
please elaborate how exactly do you want me to handle it.

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 17:39

Message:
Logged In: YES 
user_id=4799

Module logging is only available in Python 2.3. SQLObject is
supposed to work with Python 2.2. You have to catch
ImportError and provide a graceful fallback.

After 0.8 I'd like to deprecate support for Python 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1417339 ] debug SQL queries recorded through logging module

[SourceForge.net <no...@so...>]

Patches item #1417339, was opened at 2006-01-28 14:51
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&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: Maxim F. Ischenko (mfi)
Assigned to: Nobody/Anonymous (nobody)
Summary: debug SQL queries recorded through logging module

Initial Comment:
The patch adds support for standard logging module for
DBConnection classes which is crucial for using
sqlobject in cgi scripts -- you can't use STDOUT
because it is sent to the browser.

Logging is activated if user specifies logger key, the
key also serves as a logger name to be used.

This is a duplicate of the previous ticket, only with a
file attacheed (hope so).

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 19:57

Message:
Logged In: YES 
user_id=4799

Aha, that's better. Can you aslo add a test that sets up a
logger (logging to a stderr or a separate file) and a patch
for documentation (describe the "logger" keyword in a DB URI)?

----------------------------------------------------------------------

Comment By: Maxim F. Ischenko (mfi)
Date: 2006-01-31 19:04

Message:
Logged In: YES 
user_id=113894

Oleg, I was considered checking for logging module but then
decided that if a person specifies 'logger' parameter to db
connection then he should know what he's doing.

If you insist, I can add some way of handling this error but
please elaborate how exactly do you want me to handle it.

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 18:39

Message:
Logged In: YES 
user_id=4799

Module logging is only available in Python 2.3. SQLObject is
supposed to work with Python 2.2. You have to catch
ImportError and provide a graceful fallback.

After 0.8 I'd like to deprecate support for Python 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1416838 ] Fix for styles.py for uppercase column names

[SourceForge.net <no...@so...>]

Patches item #1416838, was opened at 2006-01-27 22:52
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1416838&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: Rejected
Priority: 5
Submitted By: Gabriel Reid (gab_reid)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for styles.py for uppercase column names

Initial Comment:
If a database column name is in all uppercase, with
words separated by undscores (as is the case with
column names when fetched from the data dictionary in
Firebird), the conversion from database column name to
Python attribute name and back does not work correctly,
as shown below. This is due to the fact that the style
expects a lowercase column name, which will not be the
case with Firebird connections.

Example:

>>>
>>> from sqlobject import styles
>>> style = styles.DefaultStyle()
>>>
style.pythonAttrToDBColumn(style.dbColumnToPythonAttr('START_DATE'))
'startdat_e'
>>>
style.pythonAttrToDBColumn(style.dbColumnToPythonAttr('start_date'))
'start_date'


The attached patch simply converts the column name to
lowercase before performing the conversion on it in
underToMixed.



----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 19:14

Message:
Logged In: YES 
user_id=4799

The patch is too simple, it breaks many things. For example,
test_SQLMultipleJoin.py:

            return self.FieldClass(self.tableName,
E                                 
self.soClass.sqlmeta.columns[attr].dbName,
>                                  KeyError: 'raceid'

[sqlobject/sqlbuilder.py:365]


test_SingleJoin.py:

            return self.FieldClass(self.tableName,
E                                 
self.soClass.sqlmeta.columns[attr].dbName,
>                                  KeyError: 'personid'


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1416838&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1417339 ] debug SQL queries recorded through logging module

[SourceForge.net <no...@so...>]

Patches item #1417339, was opened at 2006-01-28 13:51
Message generated for change (Comment added) made by mfi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&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: Maxim F. Ischenko (mfi)
Assigned to: Nobody/Anonymous (nobody)
Summary: debug SQL queries recorded through logging module

Initial Comment:
The patch adds support for standard logging module for
DBConnection classes which is crucial for using
sqlobject in cgi scripts -- you can't use STDOUT
because it is sent to the browser.

Logging is activated if user specifies logger key, the
key also serves as a logger name to be used.

This is a duplicate of the previous ticket, only with a
file attacheed (hope so).

----------------------------------------------------------------------

>Comment By: Maxim F. Ischenko (mfi)
Date: 2006-01-31 18:04

Message:
Logged In: YES 
user_id=113894

Oleg, I was considered checking for logging module but then
decided that if a person specifies 'logger' parameter to db
connection then he should know what he's doing.

If you insist, I can add some way of handling this error but
please elaborate how exactly do you want me to handle it.

----------------------------------------------------------------------

Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 17:39

Message:
Logged In: YES 
user_id=4799

Module logging is only available in Python 2.3. SQLObject is
supposed to work with Python 2.2. You have to catch
ImportError and provide a graceful fallback.

After 0.8 I'd like to deprecate support for Python 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1414091 ] Fix cache cleanup for new object creation

[SourceForge.net <no...@so...>]

Patches item #1414091, was opened at 2006-01-25 01:04
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1414091&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: Accepted
Priority: 5
Submitted By: Peter Kropf (peterk)
>Assigned to: Oleg Broytmann (phd)
Summary: Fix cache cleanup for new object creation

Initial Comment:
The existing CacheFactory doesn't call cull() on new
object creation. As a result, the amount of memory
consumed by a program continues to grow without bounds.

In addition, cull was never being called on get (object
lookup) operations because the cullCount variable was
not being incrimented.

The attached patch (generated via svn diff) fixes
sqlobject/cache.py so that cull is called from
created() and cullCount is incrimented for each get /
created call.  There's also a new test case in
sqlobject/tests/test_cache.py that attempts to check
for the condition where new object creation doesn't
result in culling.


----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 18:44

Message:
Logged In: YES 
user_id=4799

Applied to the trunk at the revision 1554. Thank you!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1414091&group_id=74338

[SQL-CVS] r1555 - in home/phd/SQLObject/paramstyles/sqlobject: . tests

[<sub...@co...>]

Author: phd
Date: 2006-01-31 08:43:56 -0700 (Tue, 31 Jan 2006)
New Revision: 1555

Modified:
   home/phd/SQLObject/paramstyles/sqlobject/cache.py
   home/phd/SQLObject/paramstyles/sqlobject/tests/test_cache.py
Log:
Merged patches from the revisions 1553:1554 from the trunk: applied patch 1414091: Fix cache cleanup for new object creation.

Modified: home/phd/SQLObject/paramstyles/sqlobject/cache.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/cache.py	2006-01-31 15:43:08 UTC (rev 1554)
+++ home/phd/SQLObject/paramstyles/sqlobject/cache.py	2006-01-31 15:43:56 UTC (rev 1555)
@@ -43,7 +43,7 @@
         """
 
         self.cullFrequency = cullFrequency
-        self.cullCount = cullFrequency
+        self.cullCount = 0
         self.cullOffset = 0
         self.cullFraction = cullFraction
         self.doCache = cache
@@ -97,6 +97,8 @@
                 # method has a lock, so it's threadsafe.
                 self.cullCount = 0
                 self.cull()
+            else:
+                self.cullCount = self.cullCount + 1
 
             try:
                 return self.cache[id]
@@ -166,6 +168,15 @@
         of this situation.
         """
         if self.doCache:
+            if self.cullCount > self.cullFrequency:
+                # Two threads could hit the cull in a row, but
+                # that's not so bad.  At least by setting cullCount
+                # back to zero right away we avoid this.  The cull
+                # method has a lock, so it's threadsafe.
+                self.cullCount = 0
+                self.cull()
+            else:
+                self.cullCount = self.cullCount + 1
             self.cache[id] = obj
         else:
             self.expiredCache[id] = ref(obj)

Modified: home/phd/SQLObject/paramstyles/sqlobject/tests/test_cache.py
===================================================================
--- home/phd/SQLObject/paramstyles/sqlobject/tests/test_cache.py	2006-01-31 15:43:08 UTC (rev 1554)
+++ home/phd/SQLObject/paramstyles/sqlobject/tests/test_cache.py	2006-01-31 15:43:56 UTC (rev 1555)
@@ -45,4 +45,9 @@
     CacheTest._connection.expireAll()
     s = CacheTest.get(s_id)
     assert id(s) != obj_id and id(s) != obj_id2
-    
+
+def test_cache_cull():
+    setupClass(CacheTest)
+    s = CacheTest(name='test_cache_create')
+    list = [CacheTest(name='test_cache_create %d' % count) for count in range(s._connection.cache.caches['CacheTest'].cullFrequency)]
+    assert len(s._connection.cache.caches['CacheTest'].cache) < s._connection.cache.caches['CacheTest'].cullFrequency

[SQL-CVS] r1554 - in SQLObject/trunk/sqlobject: . tests

[<sub...@co...>]

Author: phd
Date: 2006-01-31 08:43:08 -0700 (Tue, 31 Jan 2006)
New Revision: 1554

Modified:
   SQLObject/trunk/sqlobject/cache.py
   SQLObject/trunk/sqlobject/tests/test_cache.py
Log:
Applied patch 1414091: Fix cache cleanup for new object creation.


Modified: SQLObject/trunk/sqlobject/cache.py
===================================================================
--- SQLObject/trunk/sqlobject/cache.py	2006-01-31 13:42:36 UTC (rev 1553)
+++ SQLObject/trunk/sqlobject/cache.py	2006-01-31 15:43:08 UTC (rev 1554)
@@ -43,7 +43,7 @@
         """
 
         self.cullFrequency = cullFrequency
-        self.cullCount = cullFrequency
+        self.cullCount = 0
         self.cullOffset = 0
         self.cullFraction = cullFraction
         self.doCache = cache
@@ -97,6 +97,8 @@
                 # method has a lock, so it's threadsafe.
                 self.cullCount = 0
                 self.cull()
+            else:
+                self.cullCount = self.cullCount + 1
 
             try:
                 return self.cache[id]
@@ -166,6 +168,15 @@
         of this situation.
         """
         if self.doCache:
+            if self.cullCount > self.cullFrequency:
+                # Two threads could hit the cull in a row, but
+                # that's not so bad.  At least by setting cullCount
+                # back to zero right away we avoid this.  The cull
+                # method has a lock, so it's threadsafe.
+                self.cullCount = 0
+                self.cull()
+            else:
+                self.cullCount = self.cullCount + 1
             self.cache[id] = obj
         else:
             self.expiredCache[id] = ref(obj)

Modified: SQLObject/trunk/sqlobject/tests/test_cache.py
===================================================================
--- SQLObject/trunk/sqlobject/tests/test_cache.py	2006-01-31 13:42:36 UTC (rev 1553)
+++ SQLObject/trunk/sqlobject/tests/test_cache.py	2006-01-31 15:43:08 UTC (rev 1554)
@@ -45,4 +45,9 @@
     CacheTest._connection.expireAll()
     s = CacheTest.get(s_id)
     assert id(s) != obj_id and id(s) != obj_id2
-    
+
+def test_cache_cull():
+    setupClass(CacheTest)
+    s = CacheTest(name='test_cache_create')
+    list = [CacheTest(name='test_cache_create %d' % count) for count in range(s._connection.cache.caches['CacheTest'].cullFrequency)]
+    assert len(s._connection.cache.caches['CacheTest'].cache) < s._connection.cache.caches['CacheTest'].cullFrequency

[SQL-CVS] [ sqlobject-Patches-1417339 ] debug SQL queries recorded through logging module

[SourceForge.net <no...@so...>]

Patches item #1417339, was opened at 2006-01-28 14:51
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&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: Maxim F. Ischenko (mfi)
Assigned to: Nobody/Anonymous (nobody)
Summary: debug SQL queries recorded through logging module

Initial Comment:
The patch adds support for standard logging module for
DBConnection classes which is crucial for using
sqlobject in cgi scripts -- you can't use STDOUT
because it is sent to the browser.

Logging is activated if user specifies logger key, the
key also serves as a logger name to be used.

This is a duplicate of the previous ticket, only with a
file attacheed (hope so).

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 18:39

Message:
Logged In: YES 
user_id=4799

Module logging is only available in Python 2.3. SQLObject is
supposed to work with Python 2.2. You have to catch
ImportError and provide a graceful fallback.

After 0.8 I'd like to deprecate support for Python 2.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417339&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1417332 ] debug SQL queries recorded through logging module

[SourceForge.net <no...@so...>]

Patches item #1417332, was opened at 2006-01-28 14:42
Message generated for change (Settings changed) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417332&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: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: debug SQL queries recorded through logging module

Initial Comment:
The patch adds support for standard logging module for
DBConnection classes which is crucial for using
sqlobject in cgi scripts -- you can't use STDOUT
because it is sent to the browser.

Logging is activated if user specifies logger key, the
key also serves as a logger name to be used.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-01-28 14:44

Message:
Logged In: NO 

Weird, SF tracker didn't attach the patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1417332&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1410834 ] add RLIKE operator

[SourceForge.net <no...@so...>]

Patches item #1410834, was opened at 2006-01-20 17:21
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1410834&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: Pau Aliagas (linux4u)
Assigned to: Nobody/Anonymous (nobody)
Summary: add RLIKE operator

Initial Comment:
Well, it looks like I'm inspired.

I tried to do all the regular expression matching in
python, but it was too slow, as I need to select
records based on an expresion matching.

So I have implemented RLIKE, also known as REGEXP or
Posix Regular Expressions. You can use it as any other
operator!

mysql and firebird call it REGEXP and RLIKE
postgres calls it ~

The rest just do not support it, so I've made it behave
like "LIKE", as I did not find a standard manner not to
support it. It's not a bad solution :)

The patch is really trivial, I've tested it with many
records (in mysql) and works as expected. I've tested
the resulting SQL in postgres and it works too.

Hope you can include it.

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 18:24

Message:
Logged In: YES 
user_id=4799

There is much overlap between LIKE and RLIKE. Can you
refactor it to remove duplicate code?

----------------------------------------------------------------------

Comment By: Pau Aliagas (linux4u)
Date: 2006-01-20 18:03

Message:
Logged In: YES 
user_id=140558

Sorry, I attached the worng patch, this is the good one.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1410834&group_id=74338

[SQL-CVS] [ sqlobject-Patches-1410527 ] allow the use of foreign keys in selects (small jewel)

[SourceForge.net <no...@so...>]

Patches item #1410527, was opened at 2006-01-20 10:42
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1410527&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: Pau Aliagas (linux4u)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow the use of foreign keys in selects (small jewel)

Initial Comment:

Many times you need to make a query that needs to
filter using the foreign key. This should be trivial to
do: just adding the foreign table or foreign table
SHOULD work. But it does not.

Better see the example:

class handset_brand(SQLObject):
    brand = StringCol(alternateID = True, length = 50)
    handsets = SQLMultipleJoin('handset')

class handset(SQLObject):
    handset_brand = ForeignKey('handset_brand')
    handset_made_in = ForeignKey('country')
    model = StringCol(alternateID = True, length = 25)

class country(SQLObject):
    name StringCol(alternateID = True, length = 50)
    isocode StringCol(alternateID = True, length = 3)

Query 1
-------
I want to query the handsets of one concrete brand.

* solution 1
 ----------
Now the best way to do it would be:

handset_brands.get(4).handsets.filter(handset.q.model
== "mymodel")

but you NEED to define the MultipleJoin.

* solution 2
  ----------
You can use the dotq syntax:

handset.select(handset.q.handset_brandID==4)

For me the main problem is the you have to use the
foreign key name defined in Style, so if you change the
Style it would stop working. That's bad.

* expected behaviour
  ------------------
I'd like to be able to do:

handset.select(brandID = 4)

or

b = brand.get(4)
handset.select(brand = b)

One of both would be GREAT, but both would be AWSOME.
This is the natural way of thinking.

Query 2
-------
What if if want to filter using two foreign keys?
For instance to query the handsets of one concrete
brand made in one country.


* solution 1
  ----------
It would NOT work, you cannot query directly using both
foreign tables.

* solution 2
  ----------
You can use the dotq syntax:

handset.select(AND(handset.q.handset_brandID==4,
handset.q.countryID==1))

Again, you have to use the foreign key name defined in
Style. I try to avoid it, it feels like there SHOULD be
a better way.

* expected behaviour
  ------------------
I'd like to be able to do:

handset.select(brandID = 4, countrID = 1)

or

b = brand.get(4)
c = country.get(1)
handset.select(brand = b, country = c)

One of both, depending on the occasion, sometimes it
would be better to use one way, sometimes the other one.

In fact this is the way "INSERT" works!! Why not SELECT?


The good news is that this small patch (3 lines) add
this powerful features :)

It really was trivial to do thanks to the well-designed
code. Thanks very much for the hard work.

As expected, it passes all the tests.

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-01-31 18:20

Message:
Logged In: YES 
user_id=4799

This works in the trunk. Look at
http://svn.colorstudy.com/SQLObject/trunk/sqlobject/tests/test_foreignKey.py:

    # Select by usual way                                  
                                                  
    s = TestWorkKey.selectBy(composerID=c.id,
title='Symphony No. 9')                                         
    assert s[0]==w1                                        
                                                  
    # selectBy object                                      
                                                  
    s = TestWorkKey.selectBy(composer=c, title='Symphony No.
9')                                              
    assert s[0]==w1

Isn't it what you want?

----------------------------------------------------------------------

Comment By: Pau Aliagas (linux4u)
Date: 2006-01-20 10:51

Message:
Logged In: YES 
user_id=140558

There is a little mistake in the example: s/select/selectBy

where it says:
handset.select(brand = b, country = c)

it should say:
handset.selectBy(brand = b, country = c)

This is how it really works (select always uses the dotq
syntax).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1410527&group_id=74338

[SQL-CVS] r1553 - SQLObject/docs

[<sub...@co...>]

Author: ianb
Date: 2006-01-31 06:42:36 -0700 (Tue, 31 Jan 2006)
New Revision: 1553

Modified:
   SQLObject/docs/index.comments.txt
Log:
in page: http://pythonpaste.org/
by: MB
Add comment

Modified: SQLObject/docs/index.comments.txt
===================================================================
--- SQLObject/docs/index.comments.txt	2006-01-31 13:42:16 UTC (rev 1552)
+++ SQLObject/docs/index.comments.txt	2006-01-31 13:42:36 UTC (rev 1553)
@@ -14,3 +14,11 @@
 username: MB
 
 Sie werden jeweils nach Doppelklick gespeichert.
+==== $(example)  c +
+----------------------------------------
+date: 2006-01-31T06:42:36
+id: 3
+ip: 84.190.227.75
+username: MB
+
+Auch an unterschiedlichen Stellen geht das

[SQL-CVS] r1552 - SQLObject/docs

[<sub...@co...>]

Author: ianb
Date: 2006-01-31 06:42:16 -0700 (Tue, 31 Jan 2006)
New Revision: 1552

Modified:
   SQLObject/docs/index.comments.txt
Log:
in page: http://pythonpaste.org/
by: MB
Add comment

Modified: SQLObject/docs/index.comments.txt
===================================================================
--- SQLObject/docs/index.comments.txt	2006-01-31 13:41:48 UTC (rev 1551)
+++ SQLObject/docs/index.comments.txt	2006-01-31 13:42:16 UTC (rev 1552)
@@ -6,3 +6,11 @@
 username: MB
 
 Hier kann man Kommentare eingeben
+==== $(example)  c
+----------------------------------------
+date: 2006-01-31T06:42:16
+id: 2
+ip: 84.190.227.75
+username: MB
+
+Sie werden jeweils nach Doppelklick gespeichert.

[SQL-CVS] r1551 - SQLObject/docs

[<sub...@co...>]

Author: ianb
Date: 2006-01-31 06:41:48 -0700 (Tue, 31 Jan 2006)
New Revision: 1551

Added:
   SQLObject/docs/index.comments.txt
Log:
in page: http://pythonpaste.org/
by: MB
Add comment

Added: SQLObject/docs/index.comments.txt
===================================================================
--- SQLObject/docs/index.comments.txt	2006-01-31 13:40:33 UTC (rev 1550)
+++ SQLObject/docs/index.comments.txt	2006-01-31 13:41:48 UTC (rev 1551)
@@ -0,0 +1,8 @@
+==== $(documentation)  c + c
+----------------------------------------
+date: 2006-01-31T06:41:48
+id: 1
+ip: 84.190.227.75
+username: MB
+
+Hier kann man Kommentare eingeben

[SQL-CVS] r1550 - SQLObject/docs

[<sub...@co...>]

Author: ianb
Date: 2006-01-31 06:40:33 -0700 (Tue, 31 Jan 2006)
New Revision: 1550

Removed:
   SQLObject/docs/index.comments.txt
Log:
in page: http://pythonpaste.org/
Delete comment

Deleted: SQLObject/docs/index.comments.txt
===================================================================
--- SQLObject/docs/index.comments.txt	2006-01-31 13:39:59 UTC (rev 1549)
+++ SQLObject/docs/index.comments.txt	2006-01-31 13:40:33 UTC (rev 1550)
@@ -1,8 +0,0 @@
-==== $(documentation)  c
-----------------------------------------
-date: 2006-01-19T09:19:09
-id: 1
-ip: 62.101.91.106
-username: pippo
-
-grandetest

[SQL-CVS] r1549 - SQLObject/docs

[<sub...@co...>]

Author: ianb
Date: 2006-01-31 06:39:59 -0700 (Tue, 31 Jan 2006)
New Revision: 1549

Modified:
   SQLObject/docs/index.comments.txt
Log:
in page: http://pythonpaste.org/

Modified: SQLObject/docs/index.comments.txt
===================================================================
--- SQLObject/docs/index.comments.txt	2006-01-30 20:14:53 UTC (rev 1548)
+++ SQLObject/docs/index.comments.txt	2006-01-31 13:39:59 UTC (rev 1549)
@@ -5,5 +5,4 @@
 ip: 62.101.91.106
 username: pippo
 
-grande
-test
+grandetest

[SQL-CVS] [ sqlobject-Patches-1407684 ] object initialization threading issue

[SourceForge.net <no...@so...>]

Patches item #1407684, was opened at 2006-01-17 00:35
Message generated for change (Comment added) made by phd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1407684&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: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Oleg Broytmann (phd)
Summary: object initialization threading issue

Initial Comment:
The creation of SQL objects is not threadsafe. After stressing a 
TurboGears app with ab2 with multiple concurrent connections to a 
threaded server, the log gets filled with tracebacks like these:

15/Jan/2006:22:05:00 HTTP INFO Traceback (most recent call last): 
  File 
"/usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/
cherrypy/_cp httptools.py", 
line 96, in _run 
    applyFilters('before_main') 
  File 
"/usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/
cherrypy/fil ters/__init__.py", 
line 131, in applyFilters 
    method() 
  File "/home/alberto/turbogears/turbogears/visit.py", line 99, in
beforeMain 
    visit=self.get_visit() 
  File "/home/alberto/turbogears/turbogears/visit.py", line 139, in 
get_visit 
    return self.new_visit() 
  File "/home/alberto/turbogears/turbogears/visit.py", line 122, in 
new_visit 
    visit= TG_Visit( visit_key=visit_key, expiry=now+self.timeout ) 
  File 
"/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1500-
py2.4.egg/sqlobj ect/main.py", 
line 1197, in __init__ 
    self._create(id, **kw) 
  File 
"/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1500-
py2.4.egg/sqlobj ect/main.py", 
line 1221, in _create 
    self.set(**kw) 
  File 
"/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1500-
py2.4.egg/sqlobj ect/main.py", 
line 1142, in set 
    self._connection._SO_update(self, args) 
  File 
"/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1500-
py2.4.egg/sqlobj ect/dbconnection.py", 
line 561, in _SO_update 
    self.query("UPDATE %s SET %s WHERE %s = %s" % 
AttributeError: 'TG_Visit' object has no attribute 'id' 

15/Jan/2006:22:05:00 HTTP INFO Traceback (most recent call last): 
  File 
"/usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/
cherrypy/_cp httptools.py", 
line 96, in _run 
    applyFilters('before_main') 
  File 
"/usr/lib/python2.4/site-packages/CherryPy-2.2.0beta-py2.4.egg/
cherrypy/fil ters/__init__.py", 
line 131, in applyFilters 
    method() 
  File "/home/alberto/turbogears/turbogears/visit.py", line 99, in
beforeMain 
    visit=self.get_visit() 
  File "/home/alberto/turbogears/turbogears/visit.py", line 139, in 
get_visit 
    return self.new_visit() 
  File "/home/alberto/turbogears/turbogears/visit.py", line 122, in 
new_visit 
    visit= TG_Visit( visit_key=visit_key, expiry=now+self.timeout ) 
  File 
"/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1500-
py2.4.egg/sqlobj ect/main.py", 
line 1197, in __init__ 
    self._create(id, **kw) 
  File 
"/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1500-
py2.4.egg/sqlobj ect/main.py", 
line 1224, in _create 
    self._SO_finishCreate(id) 
  File 
"/usr/lib/python2.4/site-packages/SQLObject-0.7.1dev_r1500-
py2.4.egg/sqlobj ect/main.py", 
line 1242, in _SO_finishCreate 
    del self.sqlmeta._creating 
AttributeError: _creating 

I've found at http://pythonpaste.org/archives/message/
20051202.223718.a3adcfaa.en.html a solution to the problem, which 
is overriding __init__ on SQLObject subclasses by wrapping 
SQLObject.__init__ with a mutex acquisition and release.

I've made a patch for main.py which generalizes this approach and 
wraps __init__ for every SQLObject created. Tested under my 
environment and works fine.

The patch is also posted at the turbogears Trac at http://
trac.turbogears.org/turbogears/attachment/ticket/397/
sqlobject_threading.patch

Cheers,
Alberto Valverde
al...@to...

----------------------------------------------------------------------

>Comment By: Oleg Broytmann (phd)
Date: 2006-01-30 23:21

Message:
Logged In: YES 
user_id=4799

Applied at the revision 1546. Thank you!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-01-17 00:39

Message:
Logged In: NO 

Ooops, typo: the patch is for declarative.py, not main.py

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=540674&aid=1407684&group_id=74338