sqlobject-discuss — All things SQLObject-related

[SQLObject] SQLObject 1.6.0b1

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

Hello!

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


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

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

* Python 2.4 is no longer supported. The minimal supported version is
  Python 2.5.

* DateTimeCol and TimeCol preserve microseconds. The feature requires
  Python 2.6+ because in Python 2.5 datetime.strptime doesn't support
  '%f' format.

  WARNING: backward compatibility problem! Date/Time columns created
  with microseconds cannot be read back with older versions of
  SQLObject.

* Upgrade ez_setup to 1.4.2.

* Adapt duplicate error message strings for SQLite 3.8.

Contributors for this release are Geoffrey Wossum and Neil Muller.

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.6.0b1dev-r4713

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 back end to Oracle

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

Hi!

On Mon, Feb 24, 2014 at 11:33:22AM -0800, Andrew Philpot <ph...@is...> wrote:
> What is the status of this backend?

   Nobody worked on it for many years. For some reasons people who use
Oracle don't work on SQLObject, and those who work on SQLObject don't
have Oracle around.
   You are the only one who can bring the backend up to date. Start
here: http://svn.colorstudy.com/SQLObject/branches/0.6.1-oracle/ or
here: http://svn.colorstudy.com/SQLObject/branches/trunk-oracle/
and update OracleConnection to the latest API (see MySQLConnection and
PostgresConnection as examples). Test the result, then publish or send
it directly to me and I will happily integrate it. Your work will be
greatly appreciated!

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

[SQLObject] sqlobject back end to Oracle

[Andrew P. <ph...@is...>]

What is the status of this backend?  I'm being encouraged to deploy an 
sqlobject+MySQL app to an Oracle shop.  Assuming there is nothing 
available, are there other strategies folks have used to bridge this gap?

Andrew

Re: [SQLObject] SQLObject needs your help!

[Neil M. <drn...@gm...>]

On 13 February 2014 17:54, Simon Cross <hod...@gm...> wrote:
> Hi Oleg
>
> You're one of the most responsive and friendly maintainers I've come
> across. Thank you for all the work you've put in to SQLObject over the
> years. As a user of SQLObject, I've really appreciated it!
>

Totally agreed. Your handling of SQLObject has been excellent.

> Good luck with your other projects!

+1.

--
Neil Muller

Re: [SQLObject] SQLObject needs your help!

[Simon C. <hod...@gm...>]

Hi Oleg

You're one of the most responsive and friendly maintainers I've come
across. Thank you for all the work you've put in to SQLObject over the
years. As a user of SQLObject, I've really appreciated it!

Good luck with your other projects!

Schiavo
Simon

[SQLObject] SQLObject needs your help!

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

Hello, everyone! In his yesterday's post
http://www.ianbicking.org/blog/2014/02/saying-goodbye-to-python.html
Ian Bicking mentioned me as the person who saved him from the burden of
maintaining SQLObject. Thank you, Ian! It was an interesting experience
(and an urgent business need at that time).
   Unfortunately now is the worst time to praise me for working on
SQLObject. As everyone can see I wasn't very active the last year(s) and
this year the work stopped completely. I must apologize and explain
myself.
   I failed to build an active community. I am sorry. My communication
skills are perhaps not so good. And I certainly lack community-building
skills.
   Currently I am involved in three big projects, only one of them uses
SQLObject. I am tired and seldom have power to do anything besides my
work. Even worse, said project doesn't generate enough revenue and my
bosses decided to cut it in a month or two. After that I will have even
less incentive to work on SQLObject. I am very very sorry.
   It would be best for SQLObject and the community if someone takes
over the project and revives it. If you'd like, please step up.
   Or, if nobody wants to take the lead, I can continue working as the
integrator. Please send your patches (SourceForge tracker, mail list,
private mail directly to me), I'll test them, apply them and will
release new versions. I can help converting the repository to Mercurial
or git (I prefer git) if there are developers who are interested in
working with a distributed VCS.
   But without your work, dear developers, SQLObject is doomed.

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

Re: [SQLObject] SQLObject 1.6.0a1

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

Hi, all! A month has passed...

On Wed, Dec 25, 2013 at 04:55:37PM +0100, Oleg Broytman <ph...@ph...> wrote:
> On Wed, Dec 25, 2013 at 04:53:19PM +0100, Oleg Broytman <ph...@ph...> wrote:
> > * DateTimeCol and TimeCol preserve microseconds. The feature requires
> >   Python 2.6+ because in Python 2.5 datetime.strptime doesn't support
> >   '%f' format.
> 
>    This seems to be a fragile issue and I'd like to ask people to test
> it thoroughly. But please be warned
> 
> >   WARNING: backward compatibility problem! Date/Time columns created
> >   with microseconds cannot be read back with older versions of
> >   SQLObject.
> 
>    and don't test it on your production databases.

   Any report? Positive or negative?

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

Re: [SQLObject] SQLObject 1.6.0a1

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

On Wed, Dec 25, 2013 at 04:53:19PM +0100, Oleg Broytman <ph...@ph...> wrote:
> * DateTimeCol and TimeCol preserve microseconds. The feature requires
>   Python 2.6+ because in Python 2.5 datetime.strptime doesn't support
>   '%f' format.

   This seems to be a fragile issue and I'd like to ask people to test
it thoroughly. But please be warned

>   WARNING: backward compatibility problem! Date/Time columns created
>   with microseconds cannot be read back with older versions of
>   SQLObject.

   and don't test it on your production databases.

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

[SQLObject] SQLObject 1.6.0a1

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

Hello!

I'm pleased to announce version 1.6.0a1, the first alpha of the upcoming
release of branch 1.6 of SQLObject.


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

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

* Python 2.4 is no longer supported. The minimal supported version is
  Python 2.5.

* DateTimeCol and TimeCol preserve microseconds. The feature requires
  Python 2.6+ because in Python 2.5 datetime.strptime doesn't support
  '%f' format.

  WARNING: backward compatibility problem! Date/Time columns created
  with microseconds cannot be read back with older versions of
  SQLObject.

* Upgrade ez_setup to 1.4.2.

Contributor for this release is Geoffrey Wossum.

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.6.0a1dev-r4700

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.

[SQLObject] SQLObject 1.5.1

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

Hello!

I'm pleased to announce version 1.5.1, the first bugfix release of branch
1.5 of SQLObject.


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

* SQLiteConnection.close() now closes and reopens a connection
  to in-memory database.

Contributor for this release is Maciej (Matchek) Blizinski.

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.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] RelatedJoin allows adding item several times

[Daniel F. <fet...@go...>]

>> > I assume you have a reason not to use:
>> >
>> > class x(SQLObject):
>> >     ys = ForeignKey( 'y' )
>>
>> Well, in the real life example I have the two objects 'x' and 'y' are
>> kinda like 'article' and 'tag'. A tag can be attached to several
>> articles and an article can have several tags attached to it.
>>
>> So I guess I have to use RelatedJoin on both.
>
>    A typical task for many-to-many relation.

Eventually I ended up doing this:

################################

class x(SQLObject):
    ys = RelatedJoin( 'x' )

class y(SQLObject):
    xs = RelatedJoin( 'y' )

myx = x.get( 1 )
myy = y.get( 1 )
if myx not in myy.xs:
    myy.addX( myx )

################################

Simple enough :)

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Re: [SQLObject] RelatedJoin allows adding item several times

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

On Mon, Nov 11, 2013 at 09:57:53AM +0100, Daniel Fetchinson <fet...@go...> wrote:
> On 11/11/13, Simon Cross <hod...@gm...> wrote:
> > I assume you have a reason not to use:
> >
> > class x(SQLObject):
> >     ys = ForeignKey( 'y' )
> 
> Well, in the real life example I have the two objects 'x' and 'y' are
> kinda like 'article' and 'tag'. A tag can be attached to several
> articles and an article can have several tags attached to it.
> 
> So I guess I have to use RelatedJoin on both.

   A typical task for many-to-many relation.

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

Re: [SQLObject] RelatedJoin allows adding item several times

[Daniel F. <fet...@go...>]

On 11/11/13, Simon Cross <hod...@gm...> wrote:
> I assume you have a reason not to use:
>
> class x(SQLObject):
>     ys = ForeignKey( 'y' )

Well, in the real life example I have the two objects 'x' and 'y' are
kinda like 'article' and 'tag'. A tag can be attached to several
articles and an article can have several tags attached to it.

So I guess I have to use RelatedJoin on both.

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Re: [SQLObject] RelatedJoin allows adding item several times

[Daniel F. <fet...@go...>]

>> Perhaps it is by design but I was kind of surprised to see that if I have
>>
>> class x(SQLObject):
>>     ys = RelatedJoin( 'y' )
>>
>> class y(SQLObject):
>>     ....
>>
>> then I'm allowed to add several times the same 'y' object to 'x' via
>>
>> myx = x.get( 1 )
>> myy = y.get( 1 )
>> x.addY( myy )
>> x.addY( myy )
>> x.addY( myy )
>>
>> Is there a keyword argument to RelatedJoin or to addY that forbids this?
>
>    There is no.
>
>> Or I have to code this myself, i.e. check if an object is already
>> added, and if yes, refuse to do it?
>
>    It is application-dependent. Please remember that RelatedJoin is
> many-to-many relation using an intermediate table. I cannot contrive a
> task for which there could be a few intermediate rows with the same pair
> of id's but who knows what tasks people can devise.
>    The simplest thing you can do is to create unique indices for your
> intermediate tables. The best thing you can do is to send a patch that
> will create unique indices at the time of creation of RelatedJoin's.
> With an option to turn the indices off.

Okay, got it, then I'll try to come up with a solution along these lines.

Cheers,
Daniel


> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
>
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Re: [SQLObject] RelatedJoin allows adding item several times

[Simon C. <hod...@gm...>]

I assume you have a reason not to use:

class x(SQLObject):
    ys = ForeignKey( 'y' )

?

Re: [SQLObject] RelatedJoin allows adding item several times

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

Hi!

On Sun, Nov 10, 2013 at 10:21:21PM +0100, Daniel Fetchinson <fet...@go...> wrote:
> Perhaps it is by design but I was kind of surprised to see that if I have
> 
> class x(SQLObject):
>     ys = RelatedJoin( 'y' )
> 
> class y(SQLObject):
>     ....
> 
> then I'm allowed to add several times the same 'y' object to 'x' via
> 
> myx = x.get( 1 )
> myy = y.get( 1 )
> x.addY( myy )
> x.addY( myy )
> x.addY( myy )
> 
> Is there a keyword argument to RelatedJoin or to addY that forbids this?

   There is no.

> Or I have to code this myself, i.e. check if an object is already
> added, and if yes, refuse to do it?

   It is application-dependent. Please remember that RelatedJoin is
many-to-many relation using an intermediate table. I cannot contrive a
task for which there could be a few intermediate rows with the same pair
of id's but who knows what tasks people can devise.
   The simplest thing you can do is to create unique indices for your
intermediate tables. The best thing you can do is to send a patch that
will create unique indices at the time of creation of RelatedJoin's.
With an option to turn the indices off.

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

[SQLObject] RelatedJoin allows adding item several times

[Daniel F. <fet...@go...>]

Perhaps it is by design but I was kind of surprised to see that if I have

class x(SQLObject):
    ys = RelatedJoin( 'y' )

class y(SQLObject):
    ....

then I'm allowed to add several times the same 'y' object to 'x' via

myx = x.get( 1 )
myy = y.get( 1 )
x.addY( myy )
x.addY( myy )
x.addY( myy )

Is there a keyword argument to RelatedJoin or to addY that forbids this?
Or I have to code this myself, i.e. check if an object is already
added, and if yes, refuse to do it?

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

Re: [SQLObject] <class 'sqlobject.dberrors.ProgrammingError'>: Commands out of sync; you can't run this command now

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

Hi!

On Thu, Oct 31, 2013 at 10:40:07AM +0100, "sophana78 ." <sop...@gm...> wrote:
> Every few weeks, my web server, which uses sqlobjects, gets stuck with this
> error:
> <class 'sqlobject.dberrors.ProgrammingError'>: Commands out of sync; you
> can't run this command now
> 
> It sometime recovers after a few hundred transactions, sometime, it doesn't
> and remains stuck in this state.
> 
> It seems that all connections in the pool are "bad".
> 
> Do you know a way of reseting these connections? conn.commit()?
> conn.ping()? kill the connection (how)?
> 
> After looking at the code, I'm thinking about the following patch:
> in dbconnection.py, in _runWithConnection, I would like to catch this
> error. If it happens, I would reset the connection, then retry.
> 
> Or should I do this in mysqlconnection.py, in _executeRetry?

   Yes, I think mysqlconnection.py is a better place to handle
MySQL-specific problems.


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

Re: [SQLObject] MySQL: Commands out of sync; you can't run this command now

[sophana78 . <sop...@gm...>]

I've just noticed that I have the same problem.
But my application is multithreaded, and I use MySQL-python
(1.2.4) SQLObject (1.4.1)
The error occurs when executing a transaction.

Does anyone knows how to reset the connection?


On Wed, Apr 24, 2013 at 10:09 AM, Oleg Broytman <ph...@ph...> wrote:

> Hi!
>
> On Wed, Apr 24, 2013 at 08:51:57AM +0100, "Maciej (Matchek) Blizi??ski" <
> ma...@op...> wrote:
> > 2013/4/16 Oleg Broytman <ph...@ph...>
> > > On Tue, Apr 16, 2013 at 10:52:29AM +0100, "Maciej (Matchek)
> Blizi??ski" <ma...@op...> wrote:
> > > >   File
> "/opt/csw/lib/python/site-packages/sqlobject/mysql/mysqlconnection.py",
> > > > line 71, in makeConnection
> > > >     conn.ping(True) # Attempt to reconnect. This setting is
> persistent.
> > > > ProgrammingError: (2014, "Commands out of sync; you can't run this
> command now")
> > >
> > >    "Commands out of sync"means the application calls functions in the
> > > wrong order:
> > > https://dev.mysql.com/doc/refman/5.1/en/commands-out-of-sync.html
> > >    Is the app multithreaded? Could it be the app tries to reuse the
> same
> > > transaction in different threads?
> >
> > That was my suspicion too, but it's an wsgi application which doesn't
> > use threads. I experimented by reducing the number of wsgi application
> > copies / threads in Apache config to 1. It didn't help, so it's
> > probably not that.
> >
> > I've got an update: I noticed that MySQLdb[1] has a new version (1.2.4)
> > so I upgraded it and the problem seems to have gone away. Maybe it was
> > some interplay between SqlObject and the MySQL driver for Python, or
> > just simply the db driver had a problem.
>
>    I'm glad it's fixed. Good luck!
>
> 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_apr
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

[SQLObject] <class 'sqlobject.dberrors.ProgrammingError'>: Commands out of sync; you can't run this command now

[sophana78 . <sop...@gm...>]

Hi

Every few weeks, my web server, which uses sqlobjects, gets stuck with this
error:
<class 'sqlobject.dberrors.ProgrammingError'>: Commands out of sync; you
can't run this command now

It sometime recovers after a few hundred transactions, sometime, it doesn't
and remains stuck in this state.

It seems that all connections in the pool are "bad".

Do you know a way of reseting these connections? conn.commit()?
conn.ping()? kill the connection (how)?

After looking at the code, I'm thinking about the following patch:
in dbconnection.py, in _runWithConnection, I would like to catch this
error. If it happens, I would reset the connection, then retry.

Or should I do this in mysqlconnection.py, in _executeRetry?

Is there a way to know what was the previous transaction that causes this
problem on the connection?

Thanks for your help.

Re: [SQLObject] Temporary databases / Closing the :memory: database connection

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

Hi!

On Thu, Oct 17, 2013 at 10:01:53PM +0100, "Maciej (Matchek) Blizi??ski" <ma...@op...> wrote:
> import sqlobject
> 
> class Foo(sqlobject.SQLObject):
>   bar = sqlobject.UnicodeCol(length=250, unique=True)
> 
> db_uri = 'sqlite:/:memory:?cache=false'
> while True:
>   sqlobject.sqlhub.processConnection = sqlobject.connectionForURI(db_uri)
>   Foo.createTable()
>   sqlobject.sqlhub.processConnection.close()
>   sqlobject.sqlhub.processConnection = None
>   sqlobject.dbconnection.TheURIOpener.cachedURIs = {}
> 
> The process' memory kept growing. It started at around 30MB and was
> steadily raising up to 300MB at which point I stopped the process. I
> didn't do any more digging yet.

   The program eats my memory very quickly and fails with MemoryError in
a few seconds.

On Sat, Oct 19, 2013 at 11:44:03AM +0100, "Maciej (Matchek) Blizi??ski" <ma...@op...> wrote:
> On Fri, Oct 18, 2013 at 01:14:46AM +0400, Oleg Broytman wrote:
> >    It would be interesting to test if the problem lies in SQLite,
> > PySQLite or SQLObject.
> 
> Looks like it's not SQLite, the following runs with stable memory use at
> about 7MB, I ran it for about an hour:
> 
> import sqlite3
> while True:
>   conn = sqlite3.connect(":memory:")
>   c = conn.cursor()
>   c.execute('CREATE TABLE foo (bar TEXT);')
>   conn.commit()
>   conn.close()

   This one works for me, eats 9M at the start but doesn't grow.

   And this one also works perfectly:

import sqlobject

class Foo(sqlobject.SQLObject):
  bar = sqlobject.UnicodeCol(length=250, unique=True)

db_uri = "sqlite:/:memory:"
while True:
  Foo.setConnection(db_uri)
  Foo.createTable()
  Foo._connection.close()

   It takes 15M at startup but doesn't grow.

   Very puzzling!

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

Re: [SQLObject] Temporary databases / Closing the :memory: database connection

[Maciej (M. B. <ma...@op...>]

On Fri, Oct 18, 2013 at 01:14:46AM +0400, Oleg Broytman wrote:
>    It would be interesting to test if the problem lies in SQLite,
> PySQLite or SQLObject.

Looks like it's not SQLite, the following runs with stable memory use at
about 7MB, I ran it for about an hour:

import sqlite3
while True:
  conn = sqlite3.connect(":memory:")
  c = conn.cursor()
  c.execute('CREATE TABLE foo (bar TEXT);')
  conn.commit()
  conn.close()

At least we know that it can work. I guess the next step will be to use
a memory profiler to figure out what still holds the references but
I haven't gotten around to it yet.

Maciej

Re: [SQLObject] Temporary databases / Closing the :memory: database connection

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

On Thu, Oct 17, 2013 at 10:01:53PM +0100, "Maciej (Matchek) Blizi??ski" <ma...@op...> wrote:
> 2013/10/17 Oleg Broytman <ph...@ph...>
> import sqlobject
> 
> class Foo(sqlobject.SQLObject):
>   bar = sqlobject.UnicodeCol(length=250, unique=True)
> 
> db_uri = 'sqlite:/:memory:?cache=false'
> while True:
>   sqlobject.sqlhub.processConnection = sqlobject.connectionForURI(db_uri)
>   Foo.createTable()
>   sqlobject.sqlhub.processConnection.close()
>   sqlobject.sqlhub.processConnection = None
>   sqlobject.dbconnection.TheURIOpener.cachedURIs = {}
> 
> The process' memory kept growing. It started at around 30MB and was
> steadily raising up to 300MB

   It would be interesting to test if the problem lies in SQLite,
PySQLite or SQLObject.

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

Re: [SQLObject] Temporary databases / Closing the :memory: database connection

[Maciej (M. B. <ma...@op...>]

2013/10/17 Oleg Broytman <ph...@ph...>
>
> Hi!
>
> On Wed, Oct 16, 2013 at 10:58:24PM +0100, "Maciej (Matchek) Blizi??ski" <ma...@op...> wrote:
> > - there already is special handling for in-memory databases, so
> > maybe add a little more special handling for them; for example free
> > the memory on close().
>
>    The patch to test is attached.

Thanks!

I applied the patch and ran the the following test:

import sqlobject

class Foo(sqlobject.SQLObject):
  bar = sqlobject.UnicodeCol(length=250, unique=True)

db_uri = 'sqlite:/:memory:?cache=false'
while True:
  sqlobject.sqlhub.processConnection = sqlobject.connectionForURI(db_uri)
  Foo.createTable()
  sqlobject.sqlhub.processConnection.close()
  sqlobject.sqlhub.processConnection = None
  sqlobject.dbconnection.TheURIOpener.cachedURIs = {}

The process' memory kept growing. It started at around 30MB and was
steadily raising up to 300MB at which point I stopped the process. I
didn't do any more digging yet.

Maciej

Re: [SQLObject] Temporary databases / Closing the :memory: database connection

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

Hi!

On Wed, Oct 16, 2013 at 10:58:24PM +0100, "Maciej (Matchek) Blizi??ski" <ma...@op...> wrote:
> - there already is special handling for in-memory databases, so
> maybe add a little more special handling for them; for example free
> the memory on close().

   The patch to test is attached.

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