sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Data Transfert Object

[Ian B. <ia...@co...>]

On Fri, 2003-07-04 at 05:26, Fran=E7ois Girault wrote:
> Hi all,
>=20
> I've a new need (arg ;) ) :
>=20
> I've to minimize network traffic : I want to update an SQLObject (or
> better a collection) once I've modified all the attributes.
>=20
> I know a design pattern from j2ee/ejb : Data Transfert Object
> (www.theserverside.com provides a free book : "ejb design patterns",
> which describes DTO on page 47).=20
>=20
> This pattern says : a SQLObj produces a light object that doesn't updat=
e
> the db each an attribute is set. Once the work with this DTO is done, i=
t
> would be passed to the SQLObj so the attribute will be updated in the
> db.

Luke Opperman wrote a temporary memory transaction for SQLObject, though
I think he's been too busy since then to continue with it.  I believe he
called it MemoryTransaction -- anyway, it saved your changes in memory
until you explicitly saved them back to the database.  I believe this
would do what you want.

It would be possible to change SQLObject fairly easily to do this as
well.  There's an attribute _SO_creating, which delays database
operations during creation (so that all the values can be inserted at
once).  Using that, or something analogous, you could probably implement
something like delay and save methods.  But I think Luke's idea would be
more generally useful.

  Ian

Re: [SQLObject] SQLObject and Zope 3

[Ian B. <ia...@co...>]

On Fri, 2003-07-04 at 11:17, Sidnei da Silva wrote:
> Howdy,
> 
> Im working on integrating SQLObject and Zope3, and I must say that
> SQLObject is wonderful. So far, I had to change only one line, and I
> already have a working app. Here's my patch.

Cool... I was wondering how well it would work with Zope 3, and I'm glad
it's not too hard.  It's just too bad that Zope 2 is out of the question
:(

> However, Im doing something not that clean which is 'registering' a
> connection with DBConnection._connections by assigning directly to the
> module variable. I would like to see a method to do that (eg:
> DBConnection.registerConnection(name)), so that if it changes in the
> future, any code depending on it doesnt break :)

I'm not clear what you mean.  Can you give an example?

> Thanks for the work so far, and I hope to be able to make more
> contributions soon. Just for the records, im working on a Sybase-based
> app, but Im still prototyping, so Im using MySQL currently. Of course
> when the time comes, I will need to write a SybaseConnection class and
> I would like to contribute it back to the codebase.

Certainly that would be welcome.

  Ian

[SQLObject] SQLObject and Zope 3

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

Howdy,

Im working on integrating SQLObject and Zope3, and I must say that
SQLObject is wonderful. So far, I had to change only one line, and I
already have a working app. Here's my patch.

Index: SQLObject/SQLBuilder.py
===================================================================
RCS file: /cvsroot/sqlobject/SQLObject/SQLObject/SQLBuilder.py,v
retrieving revision 1.6
diff -u -r1.6 SQLBuilder.py
--- SQLObject/SQLBuilder.py     26 Jun 2003 08:33:56 -0000      1.6
+++ SQLObject/SQLBuilder.py     4 Jul 2003 16:13:50 -0000
@@ -108,7 +108,7 @@
     t = type(obj)
     if isinstance(obj, SQLExpression):
         return obj.sqlRepr()
-    elif t is type(""):
+    elif t is type("") or t is type (u""):
         for orig, repl in sqlStringReplace:
             obj = obj.replace(orig, repl)
         return "'%s'" % obj

However, Im doing something not that clean which is 'registering' a
connection with DBConnection._connections by assigning directly to the
module variable. I would like to see a method to do that (eg:
DBConnection.registerConnection(name)), so that if it changes in the
future, any code depending on it doesnt break :)

Thanks for the work so far, and I hope to be able to make more
contributions soon. Just for the records, im working on a Sybase-based
app, but Im still prototyping, so Im using MySQL currently. Of course
when the time comes, I will need to write a SybaseConnection class and
I would like to contribute it back to the codebase.

[]'s
-- 
Sidnei da Silva (dreamcatcher) <si...@x3...>
X3ng Web Technology <http://www.x3ng.com.br>
GNU/Linux user 257852
Debian GNU/Linux 3.0 (Sid) 2.4.20-powerpc ppc

Type louder, please.
-----------------------------------------------------------------------
Verified for virus by mail.redesul.com.br
Scanner: clamscan / ClamAV - Version 0.54 - Updated 01/07/2003

Re: [SQLObject] Data Transfert Object

[G. <fra...@cl...>]

On Fri, 04 Jul 2003 13:51:40 +0100
Matt Goodall <ma...@po...> wrote:

> Hi,

Hi Matt,

>=20
> If you *really* need a DTO then this is not going to help ...

I really need a DTO, because of lot of attribute assignments in some algori=
thms

> Hope that helps.

Not really, but thanks a lot to answer me so quickly !

BR

Fran=E7ois

Re: [SQLObject] Data Transfert Object

[Matt G. <ma...@po...>]

Hi,

If you *really* need a DTO then this is not going to help but SQLObject=20
already provides the set() method for updating multiple attributes in=20
one UPDATE statement. Consider the following code (untested):

    class Person(SQLObject):
        firstName =3D StringCol()
        lastName =3D StringCol()

    # Do an INSERT
    p =3D Person.new(firstName=3D'Matt, lastName=3D'Goodall')

    # UPDATE first_name
    p.firstName =3D 'Francois'
    # UPDATE last_name
    p.lastName =3D 'Girault'

    # UPDATE first_name and last_name in one go
    p.set(firstName=3D'Matt, lastName=3D'Goodall')

Hope that helps.

Cheers, Matt

Fran=E7ois Girault wrote:

>Hi all,
>
>I've a new need (arg ;) ) :
>
>I've to minimize network traffic : I want to update an SQLObject (or
>better a collection) once I've modified all the attributes.
>
>I know a design pattern from j2ee/ejb : Data Transfert Object
>(www.theserverside.com provides a free book : "ejb design patterns",
>which describes DTO on page 47).=20
>
>This pattern says : a SQLObj produces a light object that doesn't update
>the db each an attribute is set. Once the work with this DTO is done, it
>would be passed to the SQLObj so the attribute will be updated in the
>db.
>
>So I'm asking about what to do : adding a "passive mode" to SQLObject
>and add a "save" method to explicitly update, or adding a generated
>method getSomeClassDTO that would return the DTO.=20
>
>DTO could be implemented as a proxy over SQLObj : reading attribute on
>DTO will read on SQLObj, but setting attribute will store in a local
>cache, marking this attribute 'modified' so reading will read this
>modified value.
>
>If you have any idea about this problematic, I would appreciate a lot ;)
>
>Fran=E7ois
>
--=20
Matt Goodall, Pollenation Internet Ltd
e: ma...@po...

[SQLObject] Data Transfert Object

[G. <fra...@cl...>]

Hi all,

I've a new need (arg ;) ) :

I've to minimize network traffic : I want to update an SQLObject (or
better a collection) once I've modified all the attributes.

I know a design pattern from j2ee/ejb : Data Transfert Object
(www.theserverside.com provides a free book : "ejb design patterns",
which describes DTO on page 47).=20

This pattern says : a SQLObj produces a light object that doesn't update
the db each an attribute is set. Once the work with this DTO is done, it
would be passed to the SQLObj so the attribute will be updated in the
db.

So I'm asking about what to do : adding a "passive mode" to SQLObject
and add a "save" method to explicitly update, or adding a generated
method getSomeClassDTO that would return the DTO.=20

DTO could be implemented as a proxy over SQLObj : reading attribute on
DTO will read on SQLObj, but setting attribute will store in a local
cache, marking this attribute 'modified' so reading will read this
modified value.

If you have any idea about this problematic, I would appreciate a lot ;)

Fran=E7ois

[SQLObject] dropTable and Sequences

[Brad B. <br...@bb...>]

Hi all,

dropTable() does not drop the associated sequence.

I would like to submit a patch for this (with unit tests, of course :),
but should dropTable drop sequences as well, or should there be a
dropSequence() method which must be called explicitly?

Given that createTable implicitly creates sequences, this might suggest
that dropTable should implicitly drop them.

Or perhaps, to be more clear there should be explicit createTable,
createSequence, dropTable and dropSequence methods and then higher-level
create() and destroy() class methods that call these...

What do you guys think?

--
Brad Bollenbach
BBnet.ca

Re: [SQLObject] Final patch for 0.4 with unit tests

[G. <fra...@cl...>]

>=20
> class Pet(SQLObject):
>     id =3D IdCol(type=3D'alpha', length=3D32)
>     code =3D StringCol()
>     name =3D StringCol()
>     toyID =3D IntCol(foreignKey=3D'Toy')
>     _joins =3D [...]
>=20

I find this way rather elegant. I'll implement in few days if I have time t=
o, but I wasn't planning to add classes to the project, like IdCol, just tu=
ning it to my needs.

But that's a pretty good suggestion, thanks.

Fran=E7ois

Re: [SQLObject] Final patch for 0.4 with unit tests

[Ian B. <ia...@co...>]

On Tue, 2003-07-01 at 11:01, Matt Goodall wrote:
> On Tue, 2003-07-01 at 15:54, Fran=E7ois Girault wrote:
>=20
> > But, as Ian says that relation object design will move in 0.5 <snip>
>=20
> Ian, is there anything documenting your plans for relations? I scanned
> the recent mailing list archives but did not see anything obvious.

Specifically joins.  Right now joins return lists of objects.  Instead I
want them to return something more like SelectResult -- an iterable
object that also has methods for adding new objects, removing, etc.=20
(Probably it will actually be a subclass of SelectResult, as
SelectResult's methods would apply as well)

  Ian

Re: [SQLObject] Final patch for 0.4 with unit tests

[Ian B. <ia...@co...>]

On Tue, 2003-07-01 at 10:56, Matt Goodall wrote:
> This is just a quick thought, and probably something for a later
> release, but couldn't an alphanumeric id be expressed something like
> this:
> 
> class Pet(SQLObject):
>     id = IdCol(type='alpha', length=32)
>     code = StringCol()
>     name = StringCol()
>     toyID = IntCol(foreignKey='Toy')
>     _joins = [...]

Yes, I think this is better.  Or rather:

class Pet(SQLObject):
    id = StringCol(length=32)

That it's named "id" would imply its role.  You could then use a dbName
argument in lieu of _idName.

  Ian

Re: [SQLObject] Final patch for 0.4 with unit tests

[Matt G. <ma...@po...>]

Sorry about the repeated messages, I really did only send it once.
- Matt

Re: [SQLObject] Final patch for 0.4 with unit tests

[Matt G. <ma...@po...>]

On Tue, 2003-07-01 at 15:54, Fran=E7ois Girault wrote:

> But, as Ian says that relation object design will move in 0.5 <snip>

Ian, is there anything documenting your plans for relations? I scanned
the recent mailing list archives but did not see anything obvious.

Thanks, Matt

--=20
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: ma...@po...

Re: [SQLObject] Final patch for 0.4 with unit tests

[Matt G. <ma...@po...>]

This is just a quick thought, and probably something for a later
release, but couldn't an alphanumeric id be expressed something like
this:

class Pet(SQLObject):
    id =3D IdCol(type=3D'alpha', length=3D32)
    code =3D StringCol()
    name =3D StringCol()
    toyID =3D IntCol(foreignKey=3D'Toy')
    _joins =3D [...]

class Toy(SQLObject):
    name =3D StringCol()

Note that Toy does not specify the id attribute and so uses the
automatically generated version, as currently implemented.

Sorry if I am repeating things that have already been discussed, I have
not been following the SQLObject mailing list properly until recently.

Cheers, Matt

On Tue, 2003-07-01 at 15:54, Fran=E7ois Girault wrote:
> Hello,
>=20
> I've made some tests around the features I added.
>=20
> While testing, I had to add another change : cause of alphanum ID, table =
creation was wrong and insert failed.
>=20
> So, that must be specified in the class with _idAlpha and _idLength attri=
bute.
>=20
> Same for relation : joinFieldAlpha and otherFieldAlpha are used to specif=
y this. I *know* that field size is missing, so intermediate table generati=
on has hard-coded field size (16 caracter yet).
>=20
> But, as Ian says that relation object design will move in 0.5, I haven't =
tried to specify size by another attribute (joinFieldLength and otherFieldL=
ength by example) because *I* don't need to generate table at runtime (the =
database is already generated when I launch my client)
>=20
> class Pet(SQLObject):
>     _idAlpha =3D True
>     _idLength =3D 16
>     code =3D StringCol()
>     name =3D StringCol()
>     favoriteToyID =3D IntCol(foreignKey=3D'Toy')
>     _joins =3D [RelatedJoin('Toy', joinField=3D'code', joinFieldAlpha=3DT=
rue, joinColumn=3D'pet_code', otherColumn=3D'toy_code', otherField=3D'alpha=
Code', otherFieldAlpha=3DTrue, intermediateTable=3D'pet_toy')]
>=20
> class Toy(SQLObject):
>     alphaCode =3D StringCol(alternateID=3DTrue)
>     name =3D StringCol()
>=20
>=20
> Note again that it works for *postgres only*
>=20
> Fran=E7ois
--=20
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: ma...@po...

[SQLObject] Final patch for 0.4 with unit tests

[G. <fra...@cl...>]

Hello,

I've made some tests around the features I added.

While testing, I had to add another change : cause of alphanum ID, table cr=
eation was wrong and insert failed.

So, that must be specified in the class with _idAlpha and _idLength attribu=
te.

Same for relation : joinFieldAlpha and otherFieldAlpha are used to specify =
this. I *know* that field size is missing, so intermediate table generation=
 has hard-coded field size (16 caracter yet).

But, as Ian says that relation object design will move in 0.5, I haven't tr=
ied to specify size by another attribute (joinFieldLength and otherFieldLen=
gth by example) because *I* don't need to generate table at runtime (the da=
tabase is already generated when I launch my client)

class Pet(SQLObject):
    _idAlpha =3D True
    _idLength =3D 16
    code =3D StringCol()
    name =3D StringCol()
    favoriteToyID =3D IntCol(foreignKey=3D'Toy')
    _joins =3D [RelatedJoin('Toy', joinField=3D'code', joinFieldAlpha=3DTru=
e, joinColumn=3D'pet_code', otherColumn=3D'toy_code', otherField=3D'alphaCo=
de', otherFieldAlpha=3DTrue, intermediateTable=3D'pet_toy')]

class Toy(SQLObject):
    alphaCode =3D StringCol(alternateID=3DTrue)
    name =3D StringCol()


Note again that it works for *postgres only*

Fran=E7ois

Re: [SQLObject] SQLObject 0.4rc1

[Ian B. <ia...@co...>]

Thanks for noting these.  The fixes you gave are in CVS, and they'll go
in 0.4 as well.

On Mon, 2003-06-30 at 09:33, Matt Goodall wrote:
> Using:
>     python 2.2.2
>     sqlite 2.8.3
>     pysqlite 0.4.3
>     SQLObject 0.4rc1
> 
> SQLite support seems a bit broken ...
> 
> len(Person.select('all')) - "TypeError: an integer is required". I guess 
> this is because SQLite always uses strings.
> 
> Also, when a slice does not include an upper bound, i.e. 
> Person.select('all')[10:] or Person.select('all')[1], the generated SQL 
> is missing the LIMIT part of the clause. According to the SQLite docs it 
> should include "LIMIT 0" if there is no upper bound.
> 
> All of the above work fine with PostgreSQL.
> 
> Cheers, Matt
> 
> Ian Bicking wrote:
> 
> >I believe I have everything together for SQLObject 0.4  A release
> >candidate exists at:
> >
> >http://colorstudy.com/SQLObject-0.4rc1.tar.gz
> >
> >I'd appreciate it people could give it a try, to see if there's problems
> >with the distribution or anything else.  I've also restructured and
> >rewritten a lot of the documentation, so I'd appreciate any feedback
> >anyone has on that as well.
> >
> >The changes are described in News.txt
> >
> >  Ian
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >Data Reports, E-commerce, Portals, and Forums are available now.
> >Download today and enter to win an XBOX or Visual Studio .NET.
> >http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> >_______________________________________________
> >sqlobject-discuss mailing list
> >sql...@li...
> >https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> >  
> >

Re: [SQLObject] SQLObject 0.4rc1

[Ian B. <ia...@co...>]

Thanks for noting these.  I've applied your fixes to CVS, and they'll go
in 0.4final.

On Mon, 2003-06-30 at 09:33, Matt Goodall wrote:
> Using:
>     python 2.2.2
>     sqlite 2.8.3
>     pysqlite 0.4.3
>     SQLObject 0.4rc1
> 
> SQLite support seems a bit broken ...
> 
> len(Person.select('all')) - "TypeError: an integer is required". I guess 
> this is because SQLite always uses strings.
> 
> Also, when a slice does not include an upper bound, i.e. 
> Person.select('all')[10:] or Person.select('all')[1], the generated SQL 
> is missing the LIMIT part of the clause. According to the SQLite docs it 
> should include "LIMIT 0" if there is no upper bound.
> 
> All of the above work fine with PostgreSQL.
> 
> Cheers, Matt
> 
> Ian Bicking wrote:
> 
> >I believe I have everything together for SQLObject 0.4  A release
> >candidate exists at:
> >
> >http://colorstudy.com/SQLObject-0.4rc1.tar.gz
> >
> >I'd appreciate it people could give it a try, to see if there's problems
> >with the distribution or anything else.  I've also restructured and
> >rewritten a lot of the documentation, so I'd appreciate any feedback
> >anyone has on that as well.
> >
> >The changes are described in News.txt
> >
> >  Ian
> >
> >
> >
> >
> >-------------------------------------------------------
> >This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> >Data Reports, E-commerce, Portals, and Forums are available now.
> >Download today and enter to win an XBOX or Visual Studio .NET.
> >http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> >_______________________________________________
> >sqlobject-discuss mailing list
> >sql...@li...
> >https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> >  
> >

[SQLObject] My patch for CVS version, and a bug I've found in 0.4rc1

[G. <fra...@cl...>]

> > 
> > There's several things that have changed since 0.3 -- it would be
> > helpful to do this against CVS instead.

Done, see attached diff file

> > It's very helpful if you include a unit test for any new features --
> > this is more important to me than supporting all the databases.

I haven't yet include tests yet. I'm sorry about that, but I promise there will be some in the next days.

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

I also found a bug I hadn't with release 0.3 : on a table with multiple foreign keys from the same table, SQLObject raise a value at definition time, i.e while parsing the class :

Traceback (most recent call last):
  File "BDDGen.py", line 75, in ?
    class Demande(SQLObject):
  File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 233, in __new__
    newClass.addColumn(column)
  File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 503, in addColumn
    '_SO_class_%s' % column.foreignKey)
  File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 102, in addNeedSet
    getattr(obj, attr)(cls)
  File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 404, in __new__
    val._init(id, connection, selectResults)
  File "/usr/lib/python2.2/site-packages/SQLObject/SQLObject.py", line 662, in _init
    selectResults = (connection or self._connection)._SO_selectOne(self, dbNames)
  File "/usr/lib/python2.2/site-packages/SQLObject/DBConnection.py", line 266, in _SO_selectOne
    return self.queryOne("SELECT %s FROM %s WHERE %s = %s" %
  File "/usr/lib/python2.2/site-packages/SQLObject/SQLBuilder.py", line 126, in sqlRepr
    raise ValueError, "Unknown SQL builtin type: %s for %s" % \
ValueError: Unknown SQL builtin type: <class 'SQLObject.SQLObject.MetaSQLObject'> for <class '__main__.Labo'>

my cols are defined like this : 

	Col('userID', dbName='user', foreignKey='Labo'),
	Col('couserID', dbName='couser', foreignKey='Labo'),

I've to work around, but the only way I've found now is not to use the foreignKey :(

Re: [SQLObject] SQLObject 0.4rc1

[Matt G. <ma...@po...>]

and forcing queryOne()[0] to an int (as below) fixes the len() problem 
for SQLite. That works fine with PostgreSQL and I can't think of a 
reason why it would break anything else.

def countSelect(self, select):
        q = "SELECT COUNT(*) FROM %s WHERE %s" % \
            (", ".join(select.tables),
             self.whereClauseForSelect(select, limit=0, order=0))
        val = int(self.queryOne(q)[0])
        if self.debug:
            print "COUNT results:", val
        return val

Cheers, Matt

Matt Goodall wrote:

> Using:
>    python 2.2.2
>    sqlite 2.8.3
>    pysqlite 0.4.3
>    SQLObject 0.4rc1
>
> SQLite support seems a bit broken ...
>
> len(Person.select('all')) - "TypeError: an integer is required". I 
> guess this is because SQLite always uses strings.
>
> Also, when a slice does not include an upper bound, i.e. 
> Person.select('all')[10:] or Person.select('all')[1], the generated 
> SQL is missing the LIMIT part of the clause. According to the SQLite 
> docs it should include "LIMIT 0" if there is no upper bound.
>
> All of the above work fine with PostgreSQL.
>
> Cheers, Matt
>
> Ian Bicking wrote:
>
>> I believe I have everything together for SQLObject 0.4  A release
>> candidate exists at:
>>
>> http://colorstudy.com/SQLObject-0.4rc1.tar.gz
>>
>> I'd appreciate it people could give it a try, to see if there's problems
>> with the distribution or anything else.  I've also restructured and
>> rewritten a lot of the documentation, so I'd appreciate any feedback
>> anyone has on that as well.
>>
>> The changes are described in News.txt
>>
>>  Ian
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
>> _______________________________________________
>> sqlobject-discuss mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>>  
>>
>

-- 
Matt Goodall, Pollenation Internet Ltd
e: ma...@po...
t: 0113 2252500

Re: [SQLObject] SQLObject 0.4rc1

[Matt G. <ma...@po...>]

Changing SQLiteConnection's _queryAddLimitOffset() to the following 
fixes the missing upper bound problem.

def _queryAddLimitOffset(self, query, start, end):
        if not start:
            return "%s LIMIT %i" % (query, end)
        if not end:
            return "%s LIMIT 0 OFFSET %i" % (query, start)
        return "%s LIMIT %i OFFSET %i" % (query, end-start, start)

Cheers, Matt

Matt Goodall wrote:

> Using:
>    python 2.2.2
>    sqlite 2.8.3
>    pysqlite 0.4.3
>    SQLObject 0.4rc1
>
> SQLite support seems a bit broken ...
>
> len(Person.select('all')) - "TypeError: an integer is required". I 
> guess this is because SQLite always uses strings.
>
> Also, when a slice does not include an upper bound, i.e. 
> Person.select('all')[10:] or Person.select('all')[1], the generated 
> SQL is missing the LIMIT part of the clause. According to the SQLite 
> docs it should include "LIMIT 0" if there is no upper bound.
>
> All of the above work fine with PostgreSQL.
>
> Cheers, Matt
>
> Ian Bicking wrote:
>
>> I believe I have everything together for SQLObject 0.4  A release
>> candidate exists at:
>>
>> http://colorstudy.com/SQLObject-0.4rc1.tar.gz
>>
>> I'd appreciate it people could give it a try, to see if there's problems
>> with the distribution or anything else.  I've also restructured and
>> rewritten a lot of the documentation, so I'd appreciate any feedback
>> anyone has on that as well.
>>
>> The changes are described in News.txt
>>
>>  Ian
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
>> _______________________________________________
>> sqlobject-discuss mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>>  
>>
>

-- 
Matt Goodall, Pollenation Internet Ltd
e: ma...@po...
t: 0113 2252500

Re: [SQLObject] SQLObject 0.4rc1

[Matt G. <ma...@po...>]

Using:
    python 2.2.2
    sqlite 2.8.3
    pysqlite 0.4.3
    SQLObject 0.4rc1

SQLite support seems a bit broken ...

len(Person.select('all')) - "TypeError: an integer is required". I guess 
this is because SQLite always uses strings.

Also, when a slice does not include an upper bound, i.e. 
Person.select('all')[10:] or Person.select('all')[1], the generated SQL 
is missing the LIMIT part of the clause. According to the SQLite docs it 
should include "LIMIT 0" if there is no upper bound.

All of the above work fine with PostgreSQL.

Cheers, Matt

Ian Bicking wrote:

>I believe I have everything together for SQLObject 0.4  A release
>candidate exists at:
>
>http://colorstudy.com/SQLObject-0.4rc1.tar.gz
>
>I'd appreciate it people could give it a try, to see if there's problems
>with the distribution or anything else.  I've also restructured and
>rewritten a lot of the documentation, so I'd appreciate any feedback
>anyone has on that as well.
>
>The changes are described in News.txt
>
>  Ian
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
>_______________________________________________
>sqlobject-discuss mailing list
>sql...@li...
>https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>  
>

-- 
Matt Goodall, Pollenation Internet Ltd
e: ma...@po...
t: 0113 2252500

Re: [SQLObject] A small patch around features I need

[G. <fra...@cl...>]

On 30 Jun 2003 03:37:30 -0500
Ian Bicking <ia...@co...> wrote:

> On Fri, 2003-06-27 at 11:42, Fran=E7ois Girault wrote:
> > Clarisys patch for SQLOBject 0.3
>=20
> There's several things that have changed since 0.3 -- it would be
> helpful to do this against CVS instead.

Ok, this is what i'm going to do now :)

> >   * for Postgresql usage only due to modification in DBConnection, and
> > I have no time to write & test with other DB (help welcome :) ).
>=20
> It's very helpful if you include a unit test for any new features --
> this is more important to me than supporting all the databases.

Ok I'll try to include that.

> A couple notes on the code itself:
>=20
> -        func =3D eval('lambda self: self._SO_joinList[%i].performJoin(se=
lf)' % index)
> +        func =3D eval('lambda self: self._SO_joinList[%s].performJoin(se=
lf)' % index)
>=20
> That %i isn't related to the ID.

Ok :)

> (in .new()):
> +       inst._inst_id =3D None
> +       if kw.has_key('id'):
> +           inst._inst_id =3D kw['id']
> +           del kw['id']
> +       else:
> +           if kw.has_key(inst._idName):
> +               inst._inst_id =3D kw[inst._idName]
> +               del kw[inst._idName]
>=20
> I think you're allowing people to use the database name of the column
> here, even though that's not allowed for any of the other columns.  I
> don't think that should be allowed, nor should it be generalized to the
> rest of the columns -- it just creates ambiguity in your class usage.

Ok, I agree about ambiguity. So I'll only keep 'id' field name parameter. B=
ut i have to store given id in the class otherwise I don't know how to give=
 this values as parameter in _SO_finishCreate() :

id =3D self._connection.queryInsertID(self._table, self._idName, names, val=
ues, self._inst_id)

maybe an additionnal method to _connection would be the solution.

> Anyway, I'd accept it except the _inst_id stuff, but I'd really like it
> to include a unit test (and a test which the current code wouldn't pass,
> of course :).  It would be helpful if you can also redo it against CVS.=20
> But the unit test is more important.  I am repeating that for emphasis
> ;)

Sir, yes, Sir ! ;)

Fran=E7ois

Re: [SQLObject] A small patch around features I need

[Ian B. <ia...@co...>]

On Fri, 2003-06-27 at 11:42, Fran=E7ois Girault wrote:
> Clarisys patch for SQLOBject 0.3

There's several things that have changed since 0.3 -- it would be
helpful to do this against CVS instead.

>  * id can now be passed at creation time when using db sequence is not =
appropriate
>=20
>     myNewEntity =3D Entity.new(id=3D25)
>=20
>     if Entity._idName is defined, you can also use this value as key to=
 specify the id :
>=20
>     class Entity(SQLObject):
>         _idName =3D 'code'
>         ...
>     myNewEntity =3D Entity.new(code=3D25) will work the same as previou=
s declaration
>=20
>  * object ids can be alphanumerical type. Note that you MUST specify
> id at creation time for the moment. Support for stored procedure to
> generate alphanumerical ids will come in a close future ;-)=20

This seems fine -- I suspected the problem with non-integer ID's was
mostly the occasional %i, which is most of what you've changed.

It should be easy enough to add stored procedures, at the same time
allowing differently-named sequences, or the current technique (that
uses .lastrowid, I think, and in Postgres would actually work for most
cases).

Note that primary keys are still considered immutable -- this assumption
exists in subtle ways in different parts of SQLObject, and the
assumption is probably propagated to most people's applications.

>  * relations between objects can use other fields than id (including
> alphanumerical ones). In _join class attribute you can add these
> parameter to Join children creation :
>=20
>     * joinField let you specify the field to join within your class
>=20
>     * otherField let you specify the field of the other table
>=20
>    Note that the specified fields MUST be declared as alternateID

That looks fine too, though I'm also planning to change (probably for
0.5) how the joins work, so that they create better SQL and create
smarter objects than just lists.

>   * for Postgresql usage only due to modification in DBConnection, and
> I have no time to write & test with other DB (help welcome :) ).

It's very helpful if you include a unit test for any new features --
this is more important to me than supporting all the databases.


A couple notes on the code itself:

-        func =3D eval('lambda self: self._SO_joinList[%i].performJoin(se=
lf)' % index)
+        func =3D eval('lambda self: self._SO_joinList[%s].performJoin(se=
lf)' % index)

That %i isn't related to the ID.

(in .new()):
+       inst._inst_id =3D None
+       if kw.has_key('id'):
+           inst._inst_id =3D kw['id']
+           del kw['id']
+       else:
+           if kw.has_key(inst._idName):
+               inst._inst_id =3D kw[inst._idName]
+               del kw[inst._idName]

I think you're allowing people to use the database name of the column
here, even though that's not allowed for any of the other columns.  I
don't think that should be allowed, nor should it be generalized to the
rest of the columns -- it just creates ambiguity in your class usage.



Anyway, I'd accept it except the _inst_id stuff, but I'd really like it
to include a unit test (and a test which the current code wouldn't pass,
of course :).  It would be helpful if you can also redo it against CVS.=20
But the unit test is more important.  I am repeating that for emphasis
;)

  Ian

Re: [SQLObject] SQLObject 0.4rc1

[Ian B. <ia...@co...>]

On Sat, 2003-06-28 at 18:08, Edmund Lian wrote:
> Ian Bicking wrote:
> 
> > I believe I have everything together for SQLObject 0.4  A release
> > candidate exists at:
> > 
> > http://colorstudy.com/SQLObject-0.4rc1.tar.gz
> 
> Is it wise to check out a copy from the CVS repository?

Sure, CVS is currently the same as 0.4rc1.  At least as long as I didn't
accidentally leave any files out of the tarball.

  Ian

Re: [SQLObject] SQLObject 0.4rc1

[Edmund L. <el...@in...>]

Ian Bicking wrote:

> I believe I have everything together for SQLObject 0.4  A release
> candidate exists at:
> 
> http://colorstudy.com/SQLObject-0.4rc1.tar.gz

Is it wise to check out a copy from the CVS repository?


...Edmund.

[SQLObject] SQLObject 0.4rc1

[Ian B. <ia...@co...>]

I believe I have everything together for SQLObject 0.4  A release
candidate exists at:

http://colorstudy.com/SQLObject-0.4rc1.tar.gz

I'd appreciate it people could give it a try, to see if there's problems
with the distribution or anything else.  I've also restructured and
rewritten a lot of the documentation, so I'd appreciate any feedback
anyone has on that as well.

The changes are described in News.txt

  Ian