sqlobject-discuss — All things SQLObject-related

[SQLObject] Re: Adding DB auto-timestamping to DateTimeCol

[Chris G. <ch...@il...>]

On 30 Jul 2004, Mike Watkins said:

> class Test(SQLObject):
>   foo=StrCol(length=20, default=None)
>   creation_date=DateTimeCol(default=None)
> 
> When creating new Test objects, I do not want creation_date to be set
> to null; I want the database to look after setting defaults. For the
> time being I am passing a function
> 
>   creation_date=DateTimeCol(default=date.now)
> 
> but that doesn't truly resolve the issue for me as I'd prefer to have
> the database (postgres) deal with the time stamps. This makes it
> easier to coexist with other apps or sql scripts directly manipulating
> the DB. 

That's a good point. With a cluster of machines making calls to one
central database, the date.now() could return a different time depending
on which machine the code was being run on. And, as you said, it's
better to let the DB do the timestamping when you're mixing SQLObject
with other non-SQLObject apps that also use the DB. 

I think we should fix this. How about adding a boolean to the
DateTimeCol class' constructor, like this: 

    timestamp = DateTimeCol(autoTimestamp=True)

That could work. Is "autoTimestamp" a keyword people are familiar with?
:) 

[SQLObject] support for gadfly

[Dennis H. <de...@tr...>]

http://gadfly.sourceforge.net/

Hello,

I wanted to mention the RDBMS Gadfly because it is written completely in python, transaction safe and comes with a server. It is very useful for e.g. desktop installations or live-cd's (installation support, demonstration, etc.). It just works without the need for pre-installation like SQLite. By the way, it marshals objects. There's no need for type conversions. This may help supporting it.

Regards,
Dennis

[SQLObject] GROUP BY Clause - Looking for Workaround

[CLIFFORD I. <cli...@di...>]

Hi,

I understand SQLObject does not support GROUP BY but is there a way to pass 
it through to the back end anyway? I am trying to the do equivalent of:

select group_id, count(*) from person where (expiry = '12/31/2003' or 
expiry = '12/31/2004') and active = 'YES';

Regards,

Clifford Ilkay
Dinamis Corporation
3266 Yonge Street, Suite 1419
Toronto, Ontario
Canada M4N 3P6

Tel: 416-410-3326  

Re: [SQLObject] datetime vs mx.DateTime

[Mike W. <li...@mi...>]

On Wed, 2004-08-11 at 07:42, l.m.orchard wrote:
> Heya - I'm wondering if there's a way that I can force SQLObject to use 
> datetime from the Python standard modules, as opposed to mx.DateTime?

Probably. Depends.

"Depends", as some DBAPI modules require mx.DateTime - psycopg, for
example. If you are using a DBAPI module that can utilize the Python
datetime module, you could have your own conversion override the default
date/time conversion in SQLObject.

To do this, create your own load point for SQLObject rather than
importing everything from the module itself.

i.e.

mysqlobject.py:

# a convenient load point for our custom hacked SQLObject
from sqlobject import *
from sqlobject.col import *
from sqlobject.col import SOCol
from sqlobject import constraints

# and hack/define your own Date col type, converters.
... for you to do.. ;-)

[SQLObject] datetime vs mx.DateTime

[l.m.orchard <de...@po...>]

Heya - I'm wondering if there's a way that I can force SQLObject to use 
datetime from the Python standard modules, as opposed to mx.DateTime?

I have an app that was written expecting the datetime interface 
everywhere, and then mx.DateTime was installed.  Now things are 
breaking because the expected datetime objects are returned as 
mx.DateTime, which has a totally different set of methods and 
properties.

Any advice?  (And uninstalling mx.DateTime is not one of my options.  
Also, rewriting the app to use mx.DateTime is the least favorable 
outcome.)

Thanks!

--
l.m.orchard <de...@po...> http://www.decafbad.com/
...see you space cowboy.

[SQLObject] A couple of patches: SELECT DISTINCT and index creation

[Jeremy F. <je...@go...>]

Here's a couple of patches I've been using locally with some success.

The first implements DISTINCT.  It behaves a lot like reverse(): you can
either say:
	Foo.select(..., distinct=True)
or
	res = Foo.select(...)
	res.distinct()

	# use res...

This only applies to explicit select() calls.  It doesn't really combine
properly with count(*) either; it seems the correct way to do that is
count(distinct *), but sqlite (my testing DB) doesn't implement that,
and needs a much more complex variant using DISTINCT sub-selects.  So
I've ignored that for now.


The second is an updated version of the patch I posted the other day.
It allows you to specify indexes when defining a table class.  There's
an example at the top of the patch.

Both patches are against the current SVN head.

I'd be interested to know if anyone finds these useful, or if I'm just
barking up the wrong tree.

Thanks,
	J

Re: [SQLObject] connection URI and debug?

[Marcin W. <wo...@un...>]

>
> Try something like this:
>
> connection =3D connectionForURI(dsn)
> connection.debug =3D True
>
> If that doesn't behave, there may be some implementation differences
> between PostgresConnection (which I use) and MySQL and others.

It works. Thanks.

Marcin

--=20
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr

[SQLObject] Default=None should do nothing.

[Mike W. <li...@mi...>]

Here's a problem I've run across, perhaps others have solved it:

create table test (
id serial,
foo varchar(20),
creation_date timestamp default now()
);

class Test(SQLObject):
  foo=StrCol(length=20, default=None)
  creation_date=DateTimeCol(default=None)

When creating new Test objects, I do not want creation_date to be set to
null; I want the database to look after setting defaults. For the time
being I am passing a function

  creation_date=DateTimeCol(default=date.now)

but that doesn't truly resolve the issue for me as I'd prefer to have
the database (postgres) deal with the time stamps. This makes it easier
to coexist with other apps or sql scripts directly manipulating the DB.

I understand that I can use SQLBuilder to pass a db function on, but
still if possible I'd prefer that somethings be handled in the
background by the database, and accept that I might need to use
obj.sync(), perhaps in conjunction with _lazyUpdates.

Perhaps I've missed something. It won't be the last time.

Mike

--

Meskimen's Law: There's never time to do it right, but there's always
time to do it over.

Re: [SQLObject] connection URI and debug?

[Mike W. <li...@mi...>]

On Fri, 2004-07-30 at 10:06, wo...@un... wrote:
> I use current svn 0.6 version.
> How can I view SQL when using URIs (mysql://user:pass@host/dbname)?
> Documentation says it is possible to pass the keyword argument debug=1 to
> connection object, and it works with MySQLConnection(),
> but how can I achieve the same with URI string?            

Try something like this:

connection = connectionForURI(dsn)
connection.debug = True

If that doesn't behave, there may be some implementation differences
between PostgresConnection (which I use) and MySQL and others. I've
noted some minor differences between Postgres and sqlite adaptors.

> BTW simpleperson.py example tries to set debug but fails:
> Traceback (most recent call last):
>   File "simpleperson.py", line 59, in ?
>     conn.debug = 1
> AttributeError: 'str' object has no attribute 'debug'

[SQLObject] connection URI and debug?

[<wo...@un...>]

Hi,
I use current svn 0.6 version.
How can I view SQL when using URIs (mysql://user:pass@host/dbname)?
Documentation says it is possible to pass the keyword argument debug=3D1 =
to
connection object, and it works with MySQLConnection(),
but how can I achieve the same with URI string?

BTW simpleperson.py example tries to set debug but fails:
Traceback (most recent call last):
  File "simpleperson.py", line 59, in ?
    conn.debug =3D 1
AttributeError: 'str' object has no attribute 'debug'

Marcin

--=20
Marcin Wojdyr  |  http://www.unipress.waw.pl/~wojdyr

[SQLObject] getting distinct objects and counting them

[David M. C. <da...@da...>]

I've found it pretty easy to get distinct objects from a resultset using a
generator:


  # generator that returns distinct elements from a sorted iterable
  def distinct_iter(seq):
      previous = None
      for item in seq:
          if item!=previous:
              yield item
          previous = item
  
  
  result = distinct_iter( klass.select(constraint, orderBy=klass._idName) )
  for obj in result:
      # do something with obj


However, it bothered me that there was a large upfront cost (the time
between the user clicking a button and the data being displayed) if I wanted
to know the number of distinct objects before iterating through the
resultset (e.g. to get the fraction to increment a progress bar.) 

So I came up with a "cheat" using _connection.queryAll():


  def selectIDs(klass, constraint, distinct=False):
      connection = klass._connection
      table = klass._table
      idName = klass._idName
      fromstr = ', '.join( constraint.tablesUsed() )
      if distinct:
          template = 'select distinct %s.%s from %s where %s'
      else:
          template = 'select %s.%s from %s where %s'
      sql = template % (table, idName, fromstr, constraint)
      return connection.queryAll(sql)
    
         
  rows = selectIDs(klass, constraint, distinct=True)
  count = len(rows)
  # do something with count
  for row in rows:
      obj = klass(*row)
      # do something with obj
      
  
For my data the upfront cost for the second method is less than a 10th of
that for the first method.  Also, the total time for the second method is
much shorter for cached objects, whereas the first method doesn't seem to
get any faster.  
  
Dave Cook
  
				    

Re: [SQLObject] Passthrough SQL.

[David M. C. <da...@da...>]

On Fri, May 28, 2004 at 11:49:54AM -0400, Ian Sparks wrote:

> Before I start digging into the source code does the following ability
> already exist in SQLObject and, if not, does anyone else want it.


You can do

  Klass._connection.queryAll(sql)

For example, I needed to quickly get a lookup dictionary of row IDs of a
table that were in a joined table, so that I could determine which items in
a tree widget would get expanders (without having to load all the joining
objects)

  result = Klass.select(Join_klass.q.klassID==Klass.q.id) 
  lookup = dict([(o.id,None) for o in result])

works OK, but

  dict(Klass._connection.queryAll("select klass_id, NULL from join_klass"))

is 10 times faster even with cached objects.  I think I saw that fetching
only IDs instead of objects was on the TODO list.

Dave Cook


> AFAIK SQLObject can't do complex joins. For instance, I might want to do a query like :
> 
> SELECT TimeOfRequests.* FROM TimeOffRequests INNER JOIN Users ON TimeOffRequests.cUserID = Users.cID WHERE Users.Dept = 12
> 
> The result will be a set of "A" objects so I'd like SO to treat them as such. So if SQLObject doesn't already support it what I'd like to be able to do is :
> 
> timeOffReqs = TimeOffRequests.get(passThrough="SELECT TOR.* FROM TimeOffRequests TOR INNER JOIN Users U ON TOR.cUserID = U.cID WHERE U.Dept = 12")
> 
> Obviously, I've just broken the portability of my code so if there were a more SO-ish way of doing it I'd gladly take the education. 
> 
> However, in some DB's like Firebird you can get SQL results from a StoredProc or a view or something and this pass-through capability could prove useful.
> 
> Thoughts?
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id149&alloc_id66&op=click
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

[SQLObject] Flushing the cache

[Eddie C. <ed...@ho...>]

What is the best way to completely flush the cache for a particular class? I
have the following code but it seems ungainly.

    for j in Job.select():
        if 'Job' in j._connection.cache.caches:
            for id in j._connection.cache.caches['Job'].allIDs():
                j._connection.cache.caches['Job'].expire(id)
        #    j._connection.cache.caches['Job'].flush()
        break

where Job is my SO class.  I experimented with a method in CacheFactory called
flush() like so:

    def flush(self):
        self.lock.acquire()
        for key, _ in self.cache.items():
            del self.cache[key]
        for key, _ in self.expiredCache.items():
            del self.expiredCache[key]
        self.lock.release()

which I think would be more efficient but is it correct?  It certainly works
but I'm not sure if there's some dependency I've missed.

Also, while I was poking around in Cache.py I noticed that the expireAll()
method (whose function is inconsistent with the other expire() method in that
it doesn't completely remove data from both caches - just a minor naming
nitpick) has a bug in that obj is undefined, I assume it should be value.
I'll try and remember to submit this.

I'm using 0.5.2 since I assume that it's more stable.  Is that true, if not,
why not just put it on the web page?

Also as well, the link on the web page entitled "Mostly Live CVS Tarball"
seems to be rather ancient!

Eddie

[SQLObject] [PATCH] Specifying indexes

[Jeremy F. <je...@go...>]

My app relies on SQLObject to create its tables initially.  This has the
problem that there's no way to specify indexes for each table.

This patch (against SVN head) implements an Index() class which allows
you to add indexes.  Its use is pretty simple:

from sqlobject import *
class Foo(SQLObject):
	foo = IntCol()
	bar = StringCol()
	biff = IntCol()

	idx1 = Index(foo)	 	# simple index
	idx2 = Index(bar, unique=True)	# simple unique index
	idx3 = Index((biff, foo))	# multi-column index
	idx4 = Index(((biff, 4),))	# only the first 4 chars of biff are used

There are no operations which can be applied to Indexes; they're used
implicitly (one assumes) during queries.  The only time Index() has an
actual effect is during createTable.

I've only implemented support in the databases I have on hand: SQLite
and MySQL.  Adding createIndexSQL for the other database types should be
easy.

This is also the first time I've dug about SQLObject's innards, so I'm
not really sure if I've done things right.  The mapping from a Col to
SOCol via the name seems a bit tortured.

Does this look like an acceptable way of dealing with this problem?

	J

Re: [SQLObject] Proposal: change .get(int) to .get_id(int)

[Mike W. <li...@mi...>]

On Wed, 2004-07-21 at 23:53, Luke Opperman wrote: 
> Quoting Mike Watkins <li...@mi...>:
> 
> > Proposal: change .get(int) to .get_id(int)
> I can see the naming clash, although there's a lot to implement to adapt an SO
> class to a dictionary interface - with some conceptual mismatches in my mind.
> Do you really need it to act like a dictionary, or do you just like the
> semantics of the dict.get() call

SQLObjects act like a dict now; I just wanted the flexibility to use
whatever I want for .get() so that when I do need an object that looks
and acts like a dict with a string based key, without changing the
internal mechanism SQL object uses for a key value - I can.
        
get() / keys() / values() / items() / has_hey() are used so frequently
in python, I thought it would be nice if we could make our SQLObjects
look the same, when it makes sense - but the current use of .get() gets
in the way.
     
Here's my prototypical example:

Folder(SQLObject) 
    # id implied, serial integer
    # references maintains the hierarchical relation
    references = ForeignKey('Folder', dbName='references_id')
    key = StringCol(length=255)
    title = StringCol()
[snip]
    
    def get(key):
        return Folder.select(Folder.q.key == key, Folder.q.referencesID==self.id)
        
    def has_key(key):
        result = Folder.select(Folder.q.key == key, Folder.q.referencesID==self.id)
        assert result.count() <= 1  # should never have more than one
        if result.count() == 1:
            return True

    def keys():
    def values():
    def items():
    def add_folder(key, title):
        return Folder.new(referencesID=self.id, key=key, title=title)
[snip]

The "id" attribute is a standard Postgres SERIAL integer sequence and is
the "real" sql key value. In this case I'm wanting to hid all this
behind a dict-like interface, which if I could would inlucde get() as
well as has_key() etc because I don't want accesses directly to objects
by their SQL key value. And in psuedo code, accessing the tree:
root = Folder()

    root.keys()
        'subfolder','another','mike','frank','sue'
        mike.keys()
            'documents','events','blah'


mikesdocfolder = mike.get('documents')

Just feels nice.

Agreed this is an implementation issue, the current scheme does nothing
to prevent me from implementing a workable solution. My comment was
merely that it would be nice if SQLObject out of the box would allow us
to make objects look as pythonic as possible, when the feeling moves us.

I can see this being of value when objects are being shared across
systems, projects or working teams - here, take my Folder() - and show
them the dict-like interface and most people would know how to use it


--
Mike

Q: How many existentialists does it take to screw in a lightbulb? A:
Two. One to screw it in and one to observe how the lightbulb itself
symbolizes a single incandescent beacon of subjective reality in a
netherworld of endless absurdity reaching out toward a maudlin cosmos of
nothingness.

Re: [SQLObject] Proposal: change .get(int) to .get_id(int)

[J-P L. <sql...@si...>]

Jeremy Fitzhardinge wrote:

>I personally think the transition from .new -> .get is a step backwards.
>  
>
Hear, hear!

--
J-P

Re: [SQLObject] Proposal: change .get(int) to .get_id(int)

[Jeremy F. <je...@go...>]

On Wed, 2004-07-21 at 20:10 -0700, Mike Watkins wrote:
> So it would be handy, and mildly stylish to be able to define our own
> get() without breaking the insides of SQLObject. Admittedly it will be
> more cumbersome to type three more digits when we are really after the
> "id" attribute/relation.
> 
> default - no "get()"
> 
> current "get()" changes to "get_id()" or something else.

I personally think the transition from .new -> .get is a step backwards.
It feels wrong to me that instantiating a SQLObject has the side effect
of creating a new table row, since I don't see SQLObjects as being
synonymous with table rows - I see them as just being useful local
handles for table rows.  Therefore it makes most sense to me that Foo
(id) creates a local reference to foo.id in the database, and Foo.new()
creates a new row.

Also, I get things a lot more than I create them, so adding .get()
everywhere is a fair amount of extra typing.

	J

Re: [SQLObject] Proposal: change .get(int) to .get_id(int)

[Luke O. <lu...@me...>]

Quoting Mike Watkins <li...@mi...>:

> Proposal: change .get(int) to .get_id(int)
>
> It would be nice to be able to add common pythonic methods to our
> SQLObject objects without running into collisions. i.e. for a dict-like
> object, it might be nice to hand a SQLObject instance which has

Just so we're all on the same page here, not an SO *instance*, but an SO class.

I can see the naming clash, although there's a lot to implement to adapt an SO
class to a dictionary interface - with some conceptual mismatches in my mind.
Do you really need it to act like a dictionary, or do you just like the
semantics of the dict.get() call (retreive on whatever you choose as key, for
instance, or the optional default param)? I guess I'm having a hard time
seeing the times when I would be able write code that worked interchangely on
dicts and SO classes, even if the get() naming conflict is resolved.

> Occasionally I've got a SQL relation where I don't want anyone to
> think/see or smell the serial int identity column - a unique string as
> key is what I"m after, very dict like.

alternateID, People.byName() style? I personally use this a good amount, but I
don't think it would take much work to hide this as if it were the default
.get() retrieval. (So long as those semantics are clear in the code.)


class Person(SQLObject):
  name = StringCol(alternateID=True)

Person.get_id = Person.byName

Would work. Even moreso, what if the current functionality of SQLObject.get is
renamed to _SO_get (or whatever private name), and internal functions (such as
_SO_fetchAlternateID) call that. Then the default SQLObject.get keeps the
current semantics but just calls cls._SO_get(). That would allow you to
override get() to behave like a dict if you want without messing up the
internals of your objects, or to do

Person.get = Person.byName

to stick to the current interface but use names as retrieval keys instead of
the actual database ids. (Or to do things like the column overrides,
performing pre/post processing during object retrieval)

- Luke

[SQLObject] Proposal: change .get(int) to .get_id(int)

[Mike W. <li...@mi...>]

Proposal: change .get(int) to .get_id(int)

It would be nice to be able to add common pythonic methods to our
SQLObject objects without running into collisions. i.e. for a dict-like
object, it might be nice to hand a SQLObject instance which has

def get(key):

def items():

def values():

def has_key():

etc.

That first one is the killer, .get() is used inside SQLObject, returns
the an object by the "id" relation.

Occasionally I've got a SQL relation where I don't want anyone to
think/see or smell the serial int identity column - a unique string as
key is what I"m after, very dict like.

So it would be handy, and mildly stylish to be able to define our own
get() without breaking the insides of SQLObject. Admittedly it will be
more cumbersome to type three more digits when we are really after the
"id" attribute/relation.

default - no "get()"

current "get()" changes to "get_id()" or something else.

Too little sleep, not enough time lately, if I've missed something here
please slap me gently.

Mike

Re: [SQLObject] Reimplements the constructor...

[<mic...@ya...>]

Hi Luke!

> I may be misunderstanding you, is article.title a ForeignKey to title
> that may
> be NULL (when the title comes from article.section)? If so, from a
> database
> perspective I would not duplicate the data to set article.title =
> article.section.title. If section.title changes, then you need more
> application code to correctly update the article title, etc.
> 
> Instead, transparently retrieve the section's title if the article
> has no
> title:

Hugh, oh yeah, I done something with my idea, but your idea is better,
maybe :) I coding a system to store and search my country laws, see,
the tree can be:

- law
  - title
    - section
      - subsection
        - article

or only:

- law
  - title
    - article

I done some code, and it´s working for me, look:

class Container:
  def createParentObjects(self, kw):
    _containers=['law', 'title', 'section', 'subsection', 'article']
    class_name=self.__class__.__name__.lower()
    index=_containers.index(class_name)
    containers=_containers[:index]
    # first i count how many containers was passed to the constructor
    l=[kw.has_key(x) for x in containers]
    if l.count(1)!=1:
      raise TypeError, 'You can pass only one container!'
    index=l.index(1) # there is only one index to element 1
    key=containers[index]
    # then I create the antecessors
    for container in containers[:index]:
      kw[container]=kw[key].__getattribute__(container)
    return kw

class Title(SQLObject, SubContainer):
  ...
  def __init__(self, **kw):
    SQLObject.__init__(self, **self.createParentObjects(kw))

This way I don´t need to rewrite all the constructors with the same
code, but I have the problem that I can´t change the article´s place...
I will try to implement a way using the _get_attribute idea...

thanks for all help :)

=====
--
Michel Thadeu Sabchuk
Curitiba/PR


	
	
		
_______________________________________________________
Yahoo! Mail agora com 100MB, anti-spam e antivírus grátis!
http://br.info.mail.yahoo.com/

Re: [SQLObject] Re: Leaking connections

[Sidnei da S. <si...@aw...>]

| That would be an option. I use SQLObject from inside Zope (2.7) and I  
| create a new connection on each request. How can I create a per-thread  
| cache? I didn't work with thread-crossing code yet. Do you use a  
| dictionary with the thread-id as the key?

Yup. Exactly.

-- 
Sidnei da Silva <si...@aw...>
http://awkly.org - dreamcatching :: making your dreams come true
http://www.enfoldsystems.com
http://plone.org/about/team#dreamcatcher

<radix> how many people are we going to get posting to the list "How do I do X? I can't use <perfect solution>, it doesn't fit my design" today?

Re: [SQLObject] Reimplements the constructor...

[Luke O. <lu...@me...>]

> I want to reimplement the constructor to know when I adding the article
> in a section or in a title, so, if the user adding in a section, I can
> get the title from the section, the article will always have a title,
> even if it is in a section...
>
> Is it a good idea? Thanks for any help and sorry about my poor english :)

I may be misunderstanding you, is article.title a ForeignKey to title that may
be NULL (when the title comes from article.section)? If so, from a database
perspective I would not duplicate the data to set article.title =
article.section.title. If section.title changes, then you need more
application code to correctly update the article title, etc.

Instead, transparently retrieve the section's title if the article has no
title:

class Article(sqlobject):
  title = ForeignKey('Title', default=None)
  section = ForeignKey('Section', default=None)
  ..

  def _get_title(self):
    storedTitle = self._SO_get_title()
    if storedTitle:
      return storedTitle
    else if self.section:
      return self.section.title
    else:
      return None

a = Article(section=aSection, ...)
a.title   # returns aSection.title
a.title = aTitle
a.title   # returns aTitle

Logic may not be exactly how you need it (which has precedence if an article
has both a title and a section?), but I would generally solve this in this
way: leave the data model clean and get the behavior I want by overriding the
properties. (See
http://www.sqlobject.org/docs/SQLObject.html#overriding-column-attributes if
the _get_columnName thing is unfamiliar.)

- Luke

[SQLObject] Reimplements the constructor...

[<mic...@ya...>]

Hi guys!

Can I reimplement the constructor of an object. My problem is that I
have to create an article, this article can be inside a title, and can
be inside a section, I need a tree implementation for this objects:

- title 1
  - section 1
    o article 1
  - section 2
    o article 2
  o article 3

The article can be inside a section but it´s not forced, it can be
inside the title too...

I want to reimplement the constructor to know when I adding the article
in a section or in a title, so, if the user adding in a section, I can
get the title from the section, the article will always have a title,
even if it is in a section...

Is it a good idea? Thanks for any help and sorry about my poor english :)

=====
--
Michel Thadeu Sabchuk
Curitiba/PR


	
	
		
_______________________________________________________
Yahoo! Mail agora com 100MB, anti-spam e antivírus grátis!
http://br.info.mail.yahoo.com/

[SQLObject] Re: Leaking connections

[Florian S. <flo...@gm...>]

On Mon, 19 Jul 2004 11:35:17 -0300, Sidnei da Silva <si...@aw...>  
wrote:

> On Mon, Jul 19, 2004 at 07:27:11AM -0700, Michael Watkins wrote:
> | For my purposes I created a singleton class pattern which has a
> | get_connection() method and assigns the result of this to each
> | SQLObject's _connection property.
>
> I have used a descriptor for _connection which fetches a connection
> from a global per-thread connection cache.

That would be an option. I use SQLObject from inside Zope (2.7) and I  
create a new connection on each request. How can I create a per-thread  
cache? I didn't work with thread-crossing code yet. Do you use a  
dictionary with the thread-id as the key?

Regards,
Florian Schulze

Re: [SQLObject] Can SQLObject used on zope-2.7?

[Ivo v. d. W. <vla...@gm...>]

On Thu, 15 Jul 2004 11:50:19 -0400, Roberto Melo Cavalcante
<ze...@bo...> wrote:
> Hi everybody!
> 
> As you saw on subject, We're wondering if we can use SQLObject on zope2.
> That's it.
> 

You can. I'm successfully using SQLObject with Zope and Plone. Perhaps
it's not possible to persist SQLObjects in the ZODB, but that doesn't
have to be an issue I think.

I've been less successfull allowing the import of SQLObject from
pythonscripts - I had to hack SQLObject and add some
_allow_unprotected_access_to_subobjects to classdefinitions.

Ivo

-- 
Drs. I.R. van der Wijk                                      -=-
Korte Leidsedwarsstraat 12                                 Amaze
1017 RC Amsterdam, NL                                       -=-
T +31-20-4688336         F +31-20-4688337       Zope/Plone/Content Management
W http://www.amaze.nl    E in...@am...           Open Source Solutions
W http://vanderwijk.info E iv...@am...                 Consultancy
PGP http://vanderwijk.info/pgp