sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

[Oleg B. <ph...@ph...>]

On Thu, Jul 11, 2013 at 09:45:13AM -0400, Rhubarb Sin <rhu...@gm...> wrote:
> On 7/10/13, Oleg Broytman <ph...@ph...> wrote:
> >    I tested this, it works, so I committed the change at the revision 4613:
> > http://sourceforge.net/mailarchive/forum.php?thread_name=E1Uwysp-0003DP-4G%40webwareforpython.org&forum_name=sqlobject-cvs
> >
> >    This is a major API change IMO so I'm cautious and only committed to
> > the trunk.
> >    Do you want me to release a beta version so you can test it with your
> > code?
> 
> Yes, please do so, and I'll report my results.

   Done. Waiting for a report.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 1.5.0b1

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 1.5.0b1, the first beta of the upcoming
release of branch 1.5 of SQLObject.

What's new in SQLObject
=======================

Features & Interface
--------------------

* Helpers for class Outer were changed to lookup columns in table's
  declarations.

Bugfixes
--------

* A bug was fixed in DBConnection.close(); close() doesn't raise
  an UnboundLocalError if connection pool is empty.

Contributors for this release are Patrick Gendron and Rhubarb Sin.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.5.0b1dev-r4622

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

[Oleg B. <ph...@ph...>]

On Thu, Jul 11, 2013 at 09:45:13AM -0400, Rhubarb Sin <rhu...@gm...> wrote:
> On 7/10/13, Oleg Broytman <ph...@ph...> wrote:
> >    I tested this, it works, so I committed the change at the revision 4613:
> > http://sourceforge.net/mailarchive/forum.php?thread_name=E1Uwysp-0003DP-4G%40webwareforpython.org&forum_name=sqlobject-cvs
> >
> >    This is a major API change IMO so I'm cautious and only committed to
> > the trunk.
> >    Do you want me to release a beta version so you can test it with your
> > code?
> 
> Yes, please do so, and I'll report my results.

   I hope to roll it in a few days.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

[Rhubarb S. <rhu...@gm...>]

On 7/10/13, Oleg Broytman <ph...@ph...> wrote:
>    I tested this, it works, so I committed the change at the revision 4613:
> http://sourceforge.net/mailarchive/forum.php?thread_name=E1Uwysp-0003DP-4G%40webwareforpython.org&forum_name=sqlobject-cvs
>
>    This is a major API change IMO so I'm cautious and only committed to
> the trunk.
>    Do you want me to release a beta version so you can test it with your
> code?

Yes, please do so, and I'll report my results.

Re: [SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

[Oleg B. <ph...@ph...>]

Hi!

On Sat, Jun 15, 2013 at 10:35:17PM +0400, Oleg Broytman <ph...@ph...> wrote:
> On Fri, Jun 14, 2013 at 04:57:10PM -0400, Rhubarb Sin <rhu...@gm...> wrote:
> > I was surprised when I recently discovered I had to add an extra
> > underscore to use a SQLObject class's foreign key ID when using
> > sqlobject.sqlbuilder.Outer. For example, this works:
> > 
> > EXISTS(Select(Foo.q.id, where=Outer(Bar).q.foo_ID == Foo.q.id))
> > 
> > This does not work:
> > 
> > EXISTS(Select(Foo.q.id, where=AND(Outer(Bar).q.fooID == Foo.q.id)))
> 
>    What is going on is this: Outer works only symbolically - it
> generates column names without looking into class definition. That is,
> Outer(Bar).q.foo_ID puts "bar.foo_ID" into an SQL query and
> Outer(Bar).q.fooID generates "bar.fooID" without testing if such columns
> exist. There is no column fooID in table bar, hence the second query
> produces an error. There is a column foo_id, and bar.foo_ID works
> because SQL is case-insensitive language.
> 
>    If you read sqlbuilder.py you can find that Outer implemented using
> Table and Field helper classes. I can replace them with SQLObjectField
> and SQLObjectTable:
> 
> class SQLObjectOuterField(SQLObjectField):
>     def tablesUsedImmediate(self):
>         return []
> 
> class SQLObjectOuterTable(SQLObjectTable):
>     FieldClass = SQLObjectOuterField
> 
> class SQLObjectOuter:
>     def __init__(self, table):
>         self.q = SQLObjectOuterTable(table)
> 
>    Now SQLObjectOuter(Bar).q.foo_ID doesn't work but
> SQLObjectOuter(Bar).q.fooID works exactly as you expected, as well as
> SQLObjectOuter(Bar).q.foo.
> 
>    I think I can change the implementation of Outer in sqlbuilder using
> SQLObjectTable/Field helper but that requires a lot of testing. I doubt
> I will have time for it in June.

   I tested this, it works, so I committed the change at the revision 4613:
http://sourceforge.net/mailarchive/forum.php?thread_name=E1Uwysp-0003DP-4G%40webwareforpython.org&forum_name=sqlobject-cvs

   This is a major API change IMO so I'm cautious and only committed to
the trunk.
   Do you want me to release a beta version so you can test it with your
code?

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

[Oleg B. <ph...@ph...>]

Hello! Sorry for late answer. I am very busy these days - with my
family, job, construction of our dacha...

On Fri, Jun 14, 2013 at 04:57:10PM -0400, Rhubarb Sin <rhu...@gm...> wrote:
> I was surprised when I recently discovered I had to add an extra
> underscore to use a SQLObject class's foreign key ID when using
> sqlobject.sqlbuilder.Outer. For example, this works:
> 
> EXISTS(Select(Foo.q.id, where=Outer(Bar).q.foo_ID == Foo.q.id))
> 
> This does not work:
> 
> EXISTS(Select(Foo.q.id, where=AND(Outer(Bar).q.fooID == Foo.q.id)))

   What is going on is this: Outer works only symbolically - it
generates column names without looking into class definition. That is,
Outer(Bar).q.foo_ID puts "bar.foo_ID" into an SQL query and
Outer(Bar).q.fooID generates "bar.fooID" without testing if such columns
exist. There is no column fooID in table bar, hence the second query
produces an error. There is a column foo_id, and bar.foo_ID works
because SQL is case-insensitive language.

   If you read sqlbuilder.py you can find that Outer implemented using
Table and Field helper classes. I can replace them with SQLObjectField
and SQLObjectTable:

class SQLObjectOuterField(SQLObjectField):
    def tablesUsedImmediate(self):
        return []

class SQLObjectOuterTable(SQLObjectTable):
    FieldClass = SQLObjectOuterField

class SQLObjectOuter:
    def __init__(self, table):
        self.q = SQLObjectOuterTable(table)

   Now SQLObjectOuter(Bar).q.foo_ID doesn't work but
SQLObjectOuter(Bar).q.fooID works exactly as you expected, as well as
SQLObjectOuter(Bar).q.foo.

   I think I can change the implementation of Outer in sqlbuilder using
SQLObjectTable/Field helper but that requires a lot of testing. I doubt
I will have time for it in June.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject.q.foreign_keyID vs. SQLObject.q.foreign_key_ID

[Rhubarb S. <rhu...@gm...>]

I was surprised when I recently discovered I had to add an extra
underscore to use a SQLObject class's foreign key ID when using
sqlobject.sqlbuilder.Outer. For example, this works:

EXISTS(Select(Foo.q.id, where=Outer(Bar).q.foo_ID == Foo.q.id))

This does not work:

EXISTS(Select(Foo.q.id, where=AND(Outer(Bar).q.fooID == Foo.q.id)))

I've posted an example as a Gist here:

https://gist.github.com/RhubarbSin/5785040

(That code doesn't represent the way I would normally perform a query;
I encountered the issue in a subquery of a much larger one.)

Re: [SQLObject] Why does converters.py/stringLikeConverter escape linebreaks and others

[Oleg B. <ph...@ph...>]

On Wed, Jun 05, 2013 at 06:09:34PM +0200, de...@af... wrote:
> ubuntu 12.04 server LTS has version 0.12.4 in package management. Guess 

   Ah, the joys and wonders of Debian the Stable! :-))) Yes, some
packages in Debian/Ubuntu are too stable. Stuck, I dare say. Browsers,
for example -- both FFox and Chrome. I've got a habit of upgrading them
manually. And of course I do the same for SQLObject.

> I will better install this using the suggested method on the homepage.

   Or you can download an egg and install it using easy_install. Or
download the source tarball, unpack it and run

sudo python setup.py install -O2

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Why does converters.py/stringLikeConverter escape linebreaks and others

[<de...@af...>]

Thanks again Oleg.
ubuntu 12.04 server LTS has version 0.12.4 in package management. Guess 
I will better install this using the suggested method on the homepage.

Regards Thomas

Am 05.06.2013 10:12, schrieb Oleg Broytman:
> [CC to the mailing list]
>
> On Wed, Jun 05, 2013 at 09:57:01AM +0200, de...@af... wrote:
>> Hi Oleg,
>>
>> thanks for your fast reply. It pointed me to the solution. postgres
>> 9.1 on ubtuntu server 12.04 has standard_conforming_strings enabled
>> by default.
>> Turning it off solved my problem.
>>
>> Thomas
>     Turning standard_conforming_strings off is not required since
> SQLObject 1.2: http://sqlobject.org/News.html#sqlobject-1-2-0
>
> "Support for PostgreSQL 7.* is dropped. The minimal supported version
> of PostgreSQL is 8.1 now.
>
> Quoting rules changed for PostgreSQL: SQLObject uses E'' escape string
> if the string contains characters escaped with backslash."
>
>> Am 05.06.2013 09:15, schrieb Oleg Broytman:
>>> On Wed, Jun 05, 2013 at 08:54:20AM +0200, Thomas Siemion <de...@af...> wrote:
>>>> Hey folks,
>>>>
>>>> I was wondering why the sqlrepr from converters.py is escaping
>>>> linebreaks and other chars for postgres.
>>>>
>>>> I'm talking about this piece of code:
>>>>
>>>> sqlStringReplace = [
>>>>       ("'", "''"),
>>>>       ('\\', '\\\\'),
>>>>       ('\000', '\\0'),
>>>>       ('\b', '\\b'),
>>>>       ('\n', '\\n'),
>>>>       ('\r', '\\r'),
>>>>      ('\t', '\\t'),
>>>> ]
>>>>
>>>> This causes for e.g. \ to multiply. when I comment out everything but
>>>> the escaping of the single quote everything works as aspected. I don't
>>>> see the reason why this is done in the first place.
>>>>
>>>> Could anyone please explain this to me and why this is done when saving
>>>     See
>>> http://www.postgresql.org/docs/8.4/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS
>>>
>>>     "PostgreSQL also accepts "escape" string constants, which are an
>>> extension to the SQL standard. An escape string constant is specified by
>>> writing the letter E (upper or lower case) just before the opening
>>> single quote, e.g., E'foo'. (When continuing an escape string constant
>>> across lines, write E only before the first opening quote.) Within an
>>> escape string, a backslash character (\) begins a C-like backslash
>>> escape sequence, in which the combination of backslash and following
>>> character(s) represent a special byte value, as shown in Table 4-1."
>>>
>>>     Also see https://dev.mysql.com/doc/refman/5.0/en/string-literals.html
>>>
>>>> but not undone when loaing?
>>>     Because there is no need to "undone" anything. The backend doesn't
>>> store escaped values -- it stores normal values that it sends back on
>>> SELECTing.
>>>
>>>> Regards
>>>> Thomas
>>> Oleg.
> Oleg.

Re: [SQLObject] Why does converters.py/stringLikeConverter escape linebreaks and others

[Oleg B. <ph...@ph...>]

[CC to the mailing list]

On Wed, Jun 05, 2013 at 09:57:01AM +0200, de...@af... wrote:
> 
> Hi Oleg,
> 
> thanks for your fast reply. It pointed me to the solution. postgres
> 9.1 on ubtuntu server 12.04 has standard_conforming_strings enabled
> by default.
> Turning it off solved my problem.
> 
> Thomas

   Turning standard_conforming_strings off is not required since
SQLObject 1.2: http://sqlobject.org/News.html#sqlobject-1-2-0

"Support for PostgreSQL 7.* is dropped. The minimal supported version
of PostgreSQL is 8.1 now.

Quoting rules changed for PostgreSQL: SQLObject uses E'' escape string
if the string contains characters escaped with backslash."

> Am 05.06.2013 09:15, schrieb Oleg Broytman:
> >On Wed, Jun 05, 2013 at 08:54:20AM +0200, Thomas Siemion <de...@af...> wrote:
> >>Hey folks,
> >>
> >>I was wondering why the sqlrepr from converters.py is escaping
> >>linebreaks and other chars for postgres.
> >>
> >>I'm talking about this piece of code:
> >>
> >>sqlStringReplace = [
> >>      ("'", "''"),
> >>      ('\\', '\\\\'),
> >>      ('\000', '\\0'),
> >>      ('\b', '\\b'),
> >>      ('\n', '\\n'),
> >>      ('\r', '\\r'),
> >>     ('\t', '\\t'),
> >>]
> >>
> >>This causes for e.g. \ to multiply. when I comment out everything but
> >>the escaping of the single quote everything works as aspected. I don't
> >>see the reason why this is done in the first place.
> >>
> >>Could anyone please explain this to me and why this is done when saving
> >    See
> >http://www.postgresql.org/docs/8.4/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS
> >
> >    "PostgreSQL also accepts "escape" string constants, which are an
> >extension to the SQL standard. An escape string constant is specified by
> >writing the letter E (upper or lower case) just before the opening
> >single quote, e.g., E'foo'. (When continuing an escape string constant
> >across lines, write E only before the first opening quote.) Within an
> >escape string, a backslash character (\) begins a C-like backslash
> >escape sequence, in which the combination of backslash and following
> >character(s) represent a special byte value, as shown in Table 4-1."
> >
> >    Also see https://dev.mysql.com/doc/refman/5.0/en/string-literals.html
> >
> >>but not undone when loaing?
> >    Because there is no need to "undone" anything. The backend doesn't
> >store escaped values -- it stores normal values that it sends back on
> >SELECTing.
> >
> >>Regards
> >>Thomas
> >Oleg.
> 

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Why does converters.py/stringLikeConverter escape linebreaks and others

[Oleg B. <ph...@ph...>]

On Wed, Jun 05, 2013 at 08:54:20AM +0200, Thomas Siemion <de...@af...> wrote:
> Hey folks,
> 
> I was wondering why the sqlrepr from converters.py is escaping 
> linebreaks and other chars for postgres.
> 
> I'm talking about this piece of code:
> 
> sqlStringReplace = [
>      ("'", "''"),
>      ('\\', '\\\\'),
>      ('\000', '\\0'),
>      ('\b', '\\b'),
>      ('\n', '\\n'),
>      ('\r', '\\r'),
>     ('\t', '\\t'),
> ]
> 
> This causes for e.g. \ to multiply. when I comment out everything but 
> the escaping of the single quote everything works as aspected. I don't 
> see the reason why this is done in the first place.
> 
> Could anyone please explain this to me and why this is done when saving 

   See
http://www.postgresql.org/docs/8.4/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS

   "PostgreSQL also accepts "escape" string constants, which are an
extension to the SQL standard. An escape string constant is specified by
writing the letter E (upper or lower case) just before the opening
single quote, e.g., E'foo'. (When continuing an escape string constant
across lines, write E only before the first opening quote.) Within an
escape string, a backslash character (\) begins a C-like backslash
escape sequence, in which the combination of backslash and following
character(s) represent a special byte value, as shown in Table 4-1."

   Also see https://dev.mysql.com/doc/refman/5.0/en/string-literals.html

> but not undone when loaing?

   Because there is no need to "undone" anything. The backend doesn't
store escaped values -- it stores normal values that it sends back on
SELECTing.

> Regards
> Thomas

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Why does converters.py/stringLikeConverter escape linebreaks and others

[Thomas S. <de...@af...>]

Hey folks,

I was wondering why the sqlrepr from converters.py is escaping 
linebreaks and other chars for postgres.

I'm talking about this piece of code:

sqlStringReplace = [
     ("'", "''"),
     ('\\', '\\\\'),
     ('\000', '\\0'),
     ('\b', '\\b'),
     ('\n', '\\n'),
     ('\r', '\\r'),
    ('\t', '\\t'),
]

This causes for e.g. \ to multiply. when I comment out everything but 
the escaping of the single quote everything works as aspected. I don't 
see the reason why this is done in the first place.

Could anyone please explain this to me and why this is done when saving 
but not undone when loaing?

Regards
Thomas

-- 

Programmierer
Affective Internet Services
Inh. R. Tissler
Hammer Str. 39
48153 Münster
Tel: 0251-14989390
Fax: 0251-14989395
Web: http://www.affective.de
Email: si...@af...

[SQLObject] SQLObject 1.3.3 and 1.4.1

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce bugfix releases 1.3.3 and 1.4.1.


What's new in SQLObject
=======================

* Fixed bugs in pickling and unpickling (remove/restore a weak proxy to self,
  fixed cache handling).

* Added an example of using SQLObject with web.py to the links page.

Contributors for this release are Andrew Trusty and Rhubarb Sin.

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.3.3
https://pypi.python.org/pypi/SQLObject/1.4.1

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Cache Question

[Oleg B. <ph...@ph...>]

Hello!

On Thu, May 23, 2013 at 01:48:42PM +0400, Oleg Broytman <ph...@ph...> wrote:
> On Wed, May 22, 2013 at 06:16:20PM -0600, Andrew Trusty <at...@ga...> wrote:
> > I think you just answered how the bug I reported off-list occurred but I
> > was asking about the patch from revision 4530 to 4531 (when the "Cannot
> > unpickle" ValueError was first introduced) that fixed a bug relating to
> > unpickling.
> > 
> > > http://sourceforge.net/mailarchive/forum.php?thread_name=E1SXzWF-0005Cg-9K%40webwareforpython.org&forum_name=sqlobject-cvs
> > >    The last line was not changed but id was removed from the code, that
> > > how the last line became broken.
> 
>    I think the idea is to prevent getting two rows with the same id via
> SELECT and unpickling.

   I fixed the problem but it required much more than just fixing an
issue with self.id. The worse problem was that every SQLObject instance
has a weak proxy to itself and pickling does strange things -- it calls
__getstate__ twice on pickling and calls __setstate__ twice on
unpickling. The second call to __setstate__  is certainly a source of
problems with cache.
   Perhaps it's a bug in Python, I'm not sure. I fixed the problem by
avoiding pickling the weak proxy and restoring the proxy on unpickling.
Committed in the revisions 4601, 4602 (branch 1.3), 4603 (1.4), 4604
(the trunk). I will do releases in a few hours.
   Thank you very much for helping to find and fix he problems!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Example of SQLObject with web.py

[Oleg B. <ph...@ph...>]

On Thu, May 23, 2013 at 05:50:31PM -0400, Rhubarb Sin <rhu...@gm...> wrote:
> In case anyone needs help getting SQLObject caching to play well with
> web.py (particularly with a multi-process implementation like a
> typical WSGI setup), I've posted some example code for my solution on
> GitHub:
> 
> https://github.com/RhubarbSin/example-sqlobject-webpy

   Thank you! I'll add it to the http://sqlobject.org/links.html page.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Example of SQLObject with web.py

[Rhubarb S. <rhu...@gm...>]

In case anyone needs help getting SQLObject caching to play well with
web.py (particularly with a multi-process implementation like a
typical WSGI setup), I've posted some example code for my solution on
GitHub:

https://github.com/RhubarbSin/example-sqlobject-webpy

Re: [SQLObject] Cache Question

[Oleg B. <ph...@ph...>]

Please avoid top-posting. You know the problem:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

   My answer below.

On Wed, May 22, 2013 at 06:16:20PM -0600, Andrew Trusty <at...@ga...> wrote:
> I think you just answered how the bug I reported off-list occurred but I
> was asking about the patch from revision 4530 to 4531 (when the "Cannot
> unpickle" ValueError was first introduced) that fixed a bug relating to
> unpickling.
> 
> On Wed, May 22, 2013 at 6:05 PM, Oleg Broytman <ph...@ph...> wrote:
> > On Wed, May 22, 2013 at 05:46:40PM -0600, Andrew Trusty <
> > at...@ga...> wrote:
> > > I was
> > > wondering what the bug was that was fixed in 1.2.3 that necessitated this
> > > change. The site only says "Fixed a bug in cache handling while
> > > unpickling." which I found ironic because it broke caching in my app. Was
> > > the bug a memory leak due to having multiple instances with the same ID
> > in
> > > memory or was there something else? I ask because my app never seemed to
> > > experience any adverse side effects from taking advantage of this "bug".
> >
> >    This patch, I think:
> >
> > http://sourceforge.net/mailarchive/forum.php?thread_name=E1SXzWF-0005Cg-9K%40webwareforpython.org&forum_name=sqlobject-cvs
> >    The last line was not changed but id was removed from the code, that
> > how the last line became broken.

   I think the idea is to prevent getting two rows with the same id via
SELECT and unpickling.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Cache Question

[Andrew T. <at...@ga...>]

I think you just answered how the bug I reported off-list occurred but I
was asking about the patch from revision 4530 to 4531 (when the "Cannot
unpickle" ValueError was first introduced) that fixed a bug relating to
unpickling.


On Wed, May 22, 2013 at 6:05 PM, Oleg Broytman <ph...@ph...> wrote:

> On Wed, May 22, 2013 at 05:46:40PM -0600, Andrew Trusty <
> at...@ga...> wrote:
> > I recently upgraded an application to the newest version of SQLObject
> > (previously it was using a version from early 2012).  This app was
> caching
> > SQLObject objects in Redis to avoid querying the database for commonly
> used
> > data.  But after upgrading, a bug fix released as part of SQLObject 1.2.3
> > broke the caching after running into unpickling errors.  With the new
> > version of SQLObject, it was refusing to unpickle objects that were
> already
> > in SQLObject's cache.  An example of the error message I received is
> below
> > (which comes from main.py:1692)
> >
> > eg. "Cannot unpickle User row with id=1 - a different instance with the
> id
> > already exists in the cache"
> >
> >
> > I've already worked around this to keep my caching working but I was
> > wondering what the bug was that was fixed in 1.2.3 that necessitated this
> > change. The site only says "Fixed a bug in cache handling while
> > unpickling." which I found ironic because it broke caching in my app. Was
> > the bug a memory leak due to having multiple instances with the same ID
> in
> > memory or was there something else? I ask because my app never seemed to
> > experience any adverse side effects from taking advantage of this "bug".
>
>    This patch, I think:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=E1SXzWF-0005Cg-9K%40webwareforpython.org&forum_name=sqlobject-cvs
>    The last line was not changed but id was removed from the code, that
> how the last line became broken.
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

Re: [SQLObject] Cache Question

[Oleg B. <ph...@ph...>]

On Wed, May 22, 2013 at 05:46:40PM -0600, Andrew Trusty <at...@ga...> wrote:
> I recently upgraded an application to the newest version of SQLObject
> (previously it was using a version from early 2012).  This app was caching
> SQLObject objects in Redis to avoid querying the database for commonly used
> data.  But after upgrading, a bug fix released as part of SQLObject 1.2.3
> broke the caching after running into unpickling errors.  With the new
> version of SQLObject, it was refusing to unpickle objects that were already
> in SQLObject's cache.  An example of the error message I received is below
> (which comes from main.py:1692)
> 
> eg. "Cannot unpickle User row with id=1 - a different instance with the id
> already exists in the cache"
> 
> 
> I've already worked around this to keep my caching working but I was
> wondering what the bug was that was fixed in 1.2.3 that necessitated this
> change. The site only says "Fixed a bug in cache handling while
> unpickling." which I found ironic because it broke caching in my app. Was
> the bug a memory leak due to having multiple instances with the same ID in
> memory or was there something else? I ask because my app never seemed to
> experience any adverse side effects from taking advantage of this "bug".

   This patch, I think:
http://sourceforge.net/mailarchive/forum.php?thread_name=E1SXzWF-0005Cg-9K%40webwareforpython.org&forum_name=sqlobject-cvs
   The last line was not changed but id was removed from the code, that
how the last line became broken.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] Cache Question

[Andrew T. <at...@ga...>]

I recently upgraded an application to the newest version of SQLObject
(previously it was using a version from early 2012).  This app was caching
SQLObject objects in Redis to avoid querying the database for commonly used
data.  But after upgrading, a bug fix released as part of SQLObject 1.2.3
broke the caching after running into unpickling errors.  With the new
version of SQLObject, it was refusing to unpickle objects that were already
in SQLObject's cache.  An example of the error message I received is below
(which comes from main.py:1692)

eg. "Cannot unpickle User row with id=1 - a different instance with the id
already exists in the cache"


I've already worked around this to keep my caching working but I was
wondering what the bug was that was fixed in 1.2.3 that necessitated this
change. The site only says "Fixed a bug in cache handling while
unpickling." which I found ironic because it broke caching in my app. Was
the bug a memory leak due to having multiple instances with the same ID in
memory or was there something else? I ask because my app never seemed to
experience any adverse side effects from taking advantage of this "bug".


Andrew

Re: [SQLObject] SQLObject 1.4.0

[Oleg B. <ph...@ph...>]

On Sat, May 18, 2013 at 02:06:13PM +0400, Oleg Broytman <ph...@ph...> wrote:
> I'm pleased to announce version 1.4.0, the first stable release of branch
> 1.4 of SQLObject.
> 
> What's new in SQLObject
> =======================

   Nothing changed since beta.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 1.4.0

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 1.4.0, the first stable release of branch
1.4 of SQLObject.


What's new in SQLObject
=======================

Features & Interface
--------------------

* Support for PostgreSQL 8.1 is dropped. The minimal supported version of
  PostgreSQL is 8.2 now.

* Optimization in PostgresConnection: use INSERT...RETURNING id
  to get the autoincremented id in one query instead of two
  (INSERT + SELECT id).

* Changed the way to get if the table has identity in MS SQL.

* NCHAR/NVARCHAR and N''-quoted strings for MS SQL.

Contributors for this release are Ken Lalonde and Andrew Ziem.


For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.4.0

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] 1.4.0 beta1 -- please test with MS SQL

[Oleg B. <ph...@ph...>]

On Sat, May 04, 2013 at 08:01:47PM +0400, Oleg Broytman <ph...@ph...> wrote:
> * Changed the way to get if the table has identity in MS SQL.
> 
> * NCHAR/NVARCHAR and N''-quoted strings for MS SQL.
> 
> Major contributor for this release is Andrew Ziem,

   These are major changes and I'd like to ask users of MS SQL to test
this beta release.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] SQLObject 1.4.0 beta1

[Oleg B. <ph...@ph...>]

On Sat, May 04, 2013 at 08:01:47PM +0400, Oleg Broytman <ph...@ph...> wrote:
> I'm pleased to announce version 1.4.0b1, the first beta of the upcoming
> release of branch 1.4 of SQLObject.

   I'm stopping supporting branch 1.2. Please send patches for branch
1.3, 1.4 or the trunk.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

[SQLObject] SQLObject 1.4.0 beta1

[Oleg B. <ph...@ph...>]

Hello!

I'm pleased to announce version 1.4.0b1, the first beta of the upcoming
release of branch 1.4 of SQLObject.


What's new in SQLObject
=======================

Features & Interface
--------------------

* Support for PostgreSQL 8.1 is dropped. The minimal supported version of
  PostgreSQL is 8.2 now.

* Optimization in PostgresConnection: use INSERT...RETURNING id
  to get the autoincremented id in one query instead of two
  (INSERT + SELECT id).

* Changed the way to get if the table has identity in MS SQL.

* NCHAR/NVARCHAR and N''-quoted strings for MS SQL.

Major contributor for this release is Andrew Ziem,

For a more complete list, please see the news:
http://sqlobject.org/News.html


What is SQLObject
=================

SQLObject is an object-relational mapper.  Your database tables are described
as classes, and rows are instances of those classes.  SQLObject is meant to be
easy to use and quick to get started with.

SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite,
Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB).


Where is SQLObject
==================

Site:
http://sqlobject.org

Development:
http://sqlobject.org/devel/

Mailing list:
https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss

Archives:
http://news.gmane.org/gmane.comp.python.sqlobject

Download:
https://pypi.python.org/pypi/SQLObject/1.4.0b1dev-r4593

News and changes:
http://sqlobject.org/News.html

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.