Re: [SQLObject] Close a Connection

On Tue, Mar 21, 2006 at 10:32:20PM -0600, [EMAIL PROTECTED] wrote: > # close connection > connection.close() > sqlhub.processConnection = connection # is this required? > > # do it all again > connection_string='sqlite:/' + filename.replace(':', '|') > connection = connectionForURI(connection_stri

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On 3/21/06, Ian Bicking <[EMAIL PROTECTED]> wrote: I haven't said SQLObject is a dead end.  I think the codebase needsrethinking, as well as thinking about what its scope should really be.I'll just refer you to my clp discussion with Steve vis a vis the semantics of "dead end." :) And "fragmenting

Re: [SQLObject] Close a Connection

Quoting Oleg Broytmann <[EMAIL PROTECTED]>: On Thu, Mar 16, 2006 at 08:59:43PM -0600, [EMAIL PROTECTED] wrote: But the original connection stays "open" (is that the correct word) until I terminate the instance of Python I'm running. Does connection.close() help? Oleg. -- Oleg Broytmann

[SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Asheesh Laroia <[EMAIL PROTECTED]> writes: > Let me just chime in with my idea of the holy grail here: Assuming the Python > code is stored in SVN, the Python code should detect what SVN revision the > database is consistent with. Knowing that, it could generate the migration > code via the diffs

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

On Tue, 21 Mar 2006, Justin Johnson wrote: Lastly, it would be great if there could be some collaboration on a combined administration/migration tool, similar in scope to sqlobject-admin. ORM-specific administration isn't really very useful -- especially when you can't be sure the ORM descr

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Justin Johnson wrote: > Lastly, it would be great if there could be some collaboration on a > combined administration/migration tool, similar in scope to > sqlobject-admin. ORM-specific administration isn't really very useful > -- especially when you can't be sure the ORM describes anything

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

> Lastly, it would be great if there could be some collaboration on a > combined administration/migration tool, similar in scope to > sqlobject-admin. ORM-specific administration isn't really very useful > -- especially when you can't be sure the ORM describes anything similar > to what some leg

Re: [SQLObject] Re: [Sqlalchemy-users] SQLObject and SQLAlchemy

Jonathan Ellis wrote: On 3/18/06, *Alan Franzoni* <[EMAIL PROTECTED] > wrote: Now, my 2c: do we really need *two* ORMs in the Python community? I agree that we do not. But really this sentiment should be directed towards Ian Bicking; he's finally (implicitly) a

Re: [SQLObject] Referencing Col attributes in validators

On Tue, Mar 21, 2006, Oleg Broytmann wrote: >On Sun, Mar 19, 2006 at 01:10:27PM -0800, Bill Campbell wrote: >> My problem is that I can't figure out how to get the column >> definition's ``precision'' attribute. >> >> How does one get the Col attributes within the Validator methods? > > Pass sel

Re: [SQLObject] Re: GPL License

Hi Matt, On 3/21/06, Matt Good <[EMAIL PROTECTED]> wrote: > Kevin, I have contacted the pymssql authors and they've agreed to change > it to LGPL, so this looks good. Cool. That's been my general experience when talking to library authors. > I guess I can see Oleg's point since if the import isn

[SQLObject] Re: GPL License

Kevin, I have contacted the pymssql authors and they've agreed to change it to LGPL, so this looks good. I guess I can see Oleg's point since if the import isn't executed pymssql is not "linked" in. However, this makes me nervous since the level of indirection could lead to unintentional GPL viol

Re: [SQLObject] GPL license

On 3/21/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > On Mon, Mar 20, 2006 at 05:01:38PM -0500, Matthew Good wrote: > > The mssql backend for SQLObject optionally uses pymssql, though AFAIK > > this is going to be a problem due to the GPL license of pymssql. > >SQLObject doesn't include DB AP

Re: [SQLObject] Patch: support for locking rows

On Tue, Mar 21, 2006 at 10:46:25AM +0100, David Faure wrote: > On Tuesday 21 March 2006 10:24, Oleg Broytmann wrote: > > > for i in xrange(100): > > > print i > > > > > > try: > > > agg = Aggregates.select(connection = t, forUpdate = > > > True).getOne() > > >

Re: [SQLObject] Patch: support for locking rows

On Tuesday 21 March 2006 10:24, Oleg Broytmann wrote: > > for i in xrange(100): > > print i > > > > try: > > agg = Aggregates.select(connection = t, forUpdate = > > True).getOne() > > except: > > agg = Aggregates(total = 0, connection = t) >

Re: [SQLObject] Referencing Col attributes in validators

On Sun, Mar 19, 2006 at 01:10:27PM -0800, Bill Campbell wrote: > My problem is that I can't figure out how to get the column > definition's ``precision'' attribute. > > How does one get the Col attributes within the Validator methods? Pass self or specific attributes to the validator. Look how

Re: [SQLObject] Patch: support for locking rows

On Tue, Mar 14, 2006 at 06:50:14PM +0300, Oleg Broytmann wrote: > On Thu, Mar 09, 2006 at 02:01:58PM +0100, David Faure wrote: > > OK, I have reworked the support for "select for update" so that it now > > looks like > > obj.select(forUpdate = True) > > > > Patch and testcase attached. > >

Re: [SQLObject] Patch to make tableExists work with "db.table" table name

On Tue, Mar 14, 2006 at 09:19:45PM +0100, David Faure wrote: > On Tuesday 14 March 2006 16:25, Oleg Broytmann wrote: > > def tableExists(self, tableName): > > try: > > self.query('DESCRIBE %s' % (tableName)) > > return True > > except MySQLdb.ProgrammingE

Re: [SQLObject] GPL license

On Mon, Mar 20, 2006 at 05:01:38PM -0500, Matthew Good wrote: > The mssql backend for SQLObject optionally uses pymssql, though AFAIK > this is going to be a problem due to the GPL license of pymssql. > Pyscopg is also GPL, though their license does provide some explicit > statements regarding its