sqlobject-discuss — All things SQLObject-related

Re: [SQLObject] Looking for other people's projects

[Frank B. <fb...@fo...>]

Hallo,
Ian Bicking hat gesagt: // Ian Bicking wrote:

> I'm revisiting the SQLObject homepage just a little for the 0.5.2 
> release, and I'd like to include links to any applications using 
> SQLObject, examples, wrappers, documents, articles, etc.  So if you have 
> or know of something, please email me.
> 
> If you have some code on your disk that you're not sure how to 
> distribute, email me too and maybe we can find a place for it in the 
> repository somewhere (ala webware-sandbox.sf.net).

Completely done with Webware and SQLObject 0.5: 

www.normalmailorder.de 
www.normalmailorder.com

I'm not sure if I can release the code, though.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__

Re: [SQLObject] ezSqlObject convenience wrapper

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

On Monday, March 8, 2004, at 04:31  PM, Ian Bicking wrote:

> Brad Bollenbach wrote:
>> I cannot speak for Ian obviously, though I have a pretty good hunch 
>> that if somebody sent him a big patch for SQLObject that looked 
>> anywhere near mildly sane, he'd either a.) merge it himself, or b.) 
>> offer checkin access, with the specification that it be checked in on 
>> a branch (which, for anyone who floats around the CVS repositories of 
>> Open Source projects knows that using branches for this kind of thing 
>> is standard procedure. Yes, I know, SQLObject is using svn now, but 
>> same idea.)
>
> I can't say that's entirely true.  Well, it sure better be more than 
> just "mildly sane" for one thing ;)
>
> SQLObject is starting to get a point of maturity where changes have to 
> be well thought out, because they effect backward compatibility, and 
> documented interfaces are something that should be retained for future 
> compatibility.  So I don't want bad or inferior interfaces to get into 
> SQLObject.  "Bad" or "inferior" is obviously a subjective 
> consideration, and has a lot to do with SQLObject's current and future 
> scope.  A good interface solves several of the open problems with 
> SQLObject, though any one person may only need one problem solved and 
> a different or simpler API might seem clear to that person.
>
> I do feel a certain ownership of SQLObject and its direction, so I 
> want to be involved in the design of its API, certainly in a more 
> direct way than "here's a patch to apply."  That shouldn't keep people 
> from going off and experimenting on their own, though, it just means 
> that their results would probably have to be revisited and refactored 
> when it comes back to SQLObject.

The desire to avoid bad or inferior interfaces getting into SQLObject 
is obvious, which is why I made repeated reference to doing 
experimental stuff like this, or inheritance, or any creative new idea 
on a branch (and, in so doing, at least be able to keep it all in the 
name namespace/conceptual box.) This is the way most projects handle 
this sort of thing (e.g. Zope 3, Plone, Python core etc.) Again, if 
somebody created a new module everytime they wanted to add a few new 
attributes to some of SQLObject's classes, we'd have five or six of 
these different modules floating around in no time.

Sorry guys, I'm glad we have people contributing their time and code, 
but I officially give up trying to be the voice of reason here. :)

--
Brad Bollenbach

[SQLObject] Looking for other people's projects

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

I'm revisiting the SQLObject homepage just a little for the 0.5.2 
release, and I'd like to include links to any applications using 
SQLObject, examples, wrappers, documents, articles, etc.  So if you have 
or know of something, please email me.

If you have some code on your disk that you're not sure how to 
distribute, email me too and maybe we can find a place for it in the 
repository somewhere (ala webware-sandbox.sf.net).

   Ian

Re: [SQLObject] ezSqlObject convenience wrapper

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

Brad Bollenbach wrote:
> I cannot speak for Ian obviously, though I have a pretty good hunch that 
> if somebody sent him a big patch for SQLObject that looked anywhere near 
> mildly sane, he'd either a.) merge it himself, or b.) offer checkin 
> access, with the specification that it be checked in on a branch (which, 
> for anyone who floats around the CVS repositories of Open Source 
> projects knows that using branches for this kind of thing is standard 
> procedure. Yes, I know, SQLObject is using svn now, but same idea.)

I can't say that's entirely true.  Well, it sure better be more than 
just "mildly sane" for one thing ;)

SQLObject is starting to get a point of maturity where changes have to 
be well thought out, because they effect backward compatibility, and 
documented interfaces are something that should be retained for future 
compatibility.  So I don't want bad or inferior interfaces to get into 
SQLObject.  "Bad" or "inferior" is obviously a subjective consideration, 
and has a lot to do with SQLObject's current and future scope.  A good 
interface solves several of the open problems with SQLObject, though any 
one person may only need one problem solved and a different or simpler 
API might seem clear to that person.

I do feel a certain ownership of SQLObject and its direction, so I want 
to be involved in the design of its API, certainly in a more direct way 
than "here's a patch to apply."  That shouldn't keep people from going 
off and experimenting on their own, though, it just means that their 
results would probably have to be revisited and refactored when it comes 
back to SQLObject.

> To repeat, people like David are golden to SQLObject, and to any such 
> Open Source project to which they contribute their volunteer efforts. 
> It's great to see new contributions. All I'm saying is that doing it 
> this way makes it much more hassle (prohibitively so, in fact) than it 
> needs to be to try out new possible SQLObject features.

I certainly would like to encourage David to keep doing development, and 
that we can integrate some of the things in ezSqlObject, though probably 
in a more piecemeal fashion than wholesale merging.  (In a related 
issue, I realize Daniel Savard's inheritance patch is also still out 
there, and I wish I knew exactly what to do with it...)

   Ian

Re: [SQLObject] Re: Using SQLObjects without database actions.

[Peter G. <pe...@fs...>]

> It's not a very general purpose solution though. I like the idea of having a
> kind of "update object" which looks like an SQLObject, and can be shoved
> back into the database when it's finished being updated. It would be
> especially handy if it was picklable, so that it could be used as a Webware
> session variable.

When I have made more "light" object models on relational databases I have 
always used generated unique IDs, generally 256-bit md5 sums generated on 
pesudo-random data. This way I was always ID's would always look the same no 
matter what database I used.

Either this sort of IDs can be used or the ID simply cannot be retrieved 
from a memory-only SQLObject.

/P

Re: [SQLObject] ezSqlObject convenience wrapper

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

On Monday, March 8, 2004, at 08:50  AM, jws...@ra... 
wrote:

>> This debate is becoming a pointless "yes it is", "no it isn't" sort of
>> thing though, and I can see now I won't be able to make headway on my
>> point, but my logic still stands. If everybody approached this
>> situation in the same way (e.g. Daniel with inheritance, Sidnei with
>> CASCADE and such), we'd have five or six "wrapper" packages like this
>> is no time.
>
> One would hope that these extension would be test beds for new ideas 
> and if
> worthwhile, would eventually be mainstreamed. If there were multiple
> independent code forks, that should probably be interpreted as 
> impatience
> with the development speed of the main code. Having too many people
> contributing code is a problem every project should wish for.

It's not impatience with the development speed (there were no such 
complaints to any of us with checkin access or to the list, and let's 
face it, there's only a couple of people actively contributing to the 
bleeding edge stuff, there's nothing particularly overwhelming to deal 
with here), it's just a mistake in choosing to put it another module 
when it really belongs in the main codebase (or, more likely, in a 
branch off the main codebase so that people could try it out and 
discuss before merging the branch, or the useful bits of it into HEAD.)

I cannot speak for Ian obviously, though I have a pretty good hunch 
that if somebody sent him a big patch for SQLObject that looked 
anywhere near mildly sane, he'd either a.) merge it himself, or b.) 
offer checkin access, with the specification that it be checked in on a 
branch (which, for anyone who floats around the CVS repositories of 
Open Source projects knows that using branches for this kind of thing 
is standard procedure. Yes, I know, SQLObject is using svn now, but 
same idea.)

To repeat, people like David are golden to SQLObject, and to any such 
Open Source project to which they contribute their volunteer efforts. 
It's great to see new contributions. All I'm saying is that doing it 
this way makes it much more hassle (prohibitively so, in fact) than it 
needs to be to try out new possible SQLObject features.

--
Brad Bollenbach

RE: [SQLObject] Re: Changing table structure via SQLOBject

[Ian S. <Ian...@et...>]

Ian Sparks wrote :
>>
It occured to me that it would be nice to have a dbDump() capability to =
dump all the data from the database into CSV in one file-per-table.
<<

Before anyone else has a chance to reply he then adds :

For this to work with Referential Integrity SO needs to know which =
tables are the start of the RI chain, load them first and then all the =
FK tables in order. I've been away from the SO code for a while so I =
can't remember if that information is already in there or can be easily =
extracted/extrapolated?


-----Original Message-----
From: Ian Sparks=20
Sent: Monday, March 08, 2004 12:32 PM
To: Ian Bicking; Chris Gahan
Cc: sql...@li...
Subject: RE: [SQLObject] Re: Changing table structure via SQLOBject


Ian Bicking Wrote :
>>
In many ways it would be easier than with=20
these diff applications, because you could do it procedurally.  E.g.,=20
add the new column, copy all the values over using whatever kind of=20
conversion function you want, then drop the old column, and maybe=20
rename the new column.
<<

It occured to me that it would be nice to have a dbDump() capability to =
dump all the data from the database into CSV in one file-per-table.

Then you could have a dbLoad() capability to re-load all that data to an =
empty schema.

Being able to change a database in place would be useful but often =
metadata changes cut-across transactions so you can't allow anyone else =
access to the database while you're doing it anyway. That being the case =
a dump, modify, regenerate schema, reload cycle is not too hard to bear. =
Sure, it could take some time on a large database but it'd be pretty =
safe and useful for rapid prototyping too.

My $0.02. I wish I had the time to contribute and not just cheer from =
the sidelines.


-----Original Message-----
From: Ian Bicking [mailto:ia...@co...]
Sent: Sunday, March 07, 2004 3:39 PM
To: Chris Gahan
Cc: sql...@li...
Subject: Re: [SQLObject] Re: Changing table structure via SQLOBject


On Mar 6, 2004, at 11:16 PM, Chris Gahan wrote:
> Hey, that reminds me... you know what I think would be cool?
>
> Well, probably not, so I'll tell you!
>
> A function that you can run after you've modified the attributes of an
> SQLObject which will update the database's table to add the new=20
> attributes
> and changes WITHOUT requiring you to lose all of your data (or to have =

> to
> change the table by hand)!
>
> It would only work if you've made changes that aren't impossible to=20
> convert
> (i.e. changing a StringCol() to an IntCol()). I think it would be=20
> handy. :)
>
> Is there a clever way of implementing this, or is it basically just a=20
> whole
> load of if statements....? (i.e. is there a facility in MySQL or=20
> PostgreSQL
> which lets you submit a new schema and IT figures out if it's possible =

> to
> convert the table to that?)

There's a utility called (I think) mysqldiff which compares table=20
definitions and comes up with a way to convert one to the other.  I=20
believe it tries to keep values, though obviously it could be difficult=20
(e.g., it can't tell that you meant to rename a column).  There's=20
something like pgdiff (I'm kind of making up the names here) that does=20
the same for Postgres, but I don't think it works as well -- Postgres=20
still has a bunch of restrictions when it comes to altering tables=20
(though 7.3 seems to remove several of these).

It would be an interesting task to do this with SQLObject, but I think=20
it would actually be more like a SQLObject application than part of the=20
library (though maybe not).  In many ways it would be easier than with=20
these diff applications, because you could do it procedurally.  E.g.,=20
add the new column, copy all the values over using whatever kind of=20
conversion function you want, then drop the old column, and maybe=20
rename the new column.  Way easier than with the diff utilities,=20
because it doesn't have to divine what changes you intended by looking=20
at a description of the before and after state.

I know this all gets to be a pain in Postgres because of constraints. =20
E.g., there's some recipes for deleting columns in 7.2 where you create=20
the new table, copy all the values, then rename it so its in the old=20
table's place -- but constraints and views refer to the table ID, not=20
the table name, so it's a real pain.  When I had to do this I ended up=20
just importing the database into 7.3, doing the operations, then=20
exporting the entire database back to 7.2.  But it's probably doable by=20
messing with the magic pg_ tables enough, and if it's hard that just=20
means it's better to encapsulate all that effort into a program. =20
Anyway, doing it with MySQL would be way easier.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
sqlobject-discuss mailing list
sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
sqlobject-discuss mailing list
sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

RE: [SQLObject] Re: Changing table structure via SQLOBject

[Ian S. <Ian...@et...>]

Ian Bicking Wrote :
>>
In many ways it would be easier than with=20
these diff applications, because you could do it procedurally.  E.g.,=20
add the new column, copy all the values over using whatever kind of=20
conversion function you want, then drop the old column, and maybe=20
rename the new column.
<<

It occured to me that it would be nice to have a dbDump() capability to =
dump all the data from the database into CSV in one file-per-table.

Then you could have a dbLoad() capability to re-load all that data to an =
empty schema.

Being able to change a database in place would be useful but often =
metadata changes cut-across transactions so you can't allow anyone else =
access to the database while you're doing it anyway. That being the case =
a dump, modify, regenerate schema, reload cycle is not too hard to bear. =
Sure, it could take some time on a large database but it'd be pretty =
safe and useful for rapid prototyping too.

My $0.02. I wish I had the time to contribute and not just cheer from =
the sidelines.


-----Original Message-----
From: Ian Bicking [mailto:ia...@co...]
Sent: Sunday, March 07, 2004 3:39 PM
To: Chris Gahan
Cc: sql...@li...
Subject: Re: [SQLObject] Re: Changing table structure via SQLOBject


On Mar 6, 2004, at 11:16 PM, Chris Gahan wrote:
> Hey, that reminds me... you know what I think would be cool?
>
> Well, probably not, so I'll tell you!
>
> A function that you can run after you've modified the attributes of an
> SQLObject which will update the database's table to add the new=20
> attributes
> and changes WITHOUT requiring you to lose all of your data (or to have =

> to
> change the table by hand)!
>
> It would only work if you've made changes that aren't impossible to=20
> convert
> (i.e. changing a StringCol() to an IntCol()). I think it would be=20
> handy. :)
>
> Is there a clever way of implementing this, or is it basically just a=20
> whole
> load of if statements....? (i.e. is there a facility in MySQL or=20
> PostgreSQL
> which lets you submit a new schema and IT figures out if it's possible =

> to
> convert the table to that?)

There's a utility called (I think) mysqldiff which compares table=20
definitions and comes up with a way to convert one to the other.  I=20
believe it tries to keep values, though obviously it could be difficult=20
(e.g., it can't tell that you meant to rename a column).  There's=20
something like pgdiff (I'm kind of making up the names here) that does=20
the same for Postgres, but I don't think it works as well -- Postgres=20
still has a bunch of restrictions when it comes to altering tables=20
(though 7.3 seems to remove several of these).

It would be an interesting task to do this with SQLObject, but I think=20
it would actually be more like a SQLObject application than part of the=20
library (though maybe not).  In many ways it would be easier than with=20
these diff applications, because you could do it procedurally.  E.g.,=20
add the new column, copy all the values over using whatever kind of=20
conversion function you want, then drop the old column, and maybe=20
rename the new column.  Way easier than with the diff utilities,=20
because it doesn't have to divine what changes you intended by looking=20
at a description of the before and after state.

I know this all gets to be a pain in Postgres because of constraints. =20
E.g., there's some recipes for deleting columns in 7.2 where you create=20
the new table, copy all the values, then rename it so its in the old=20
table's place -- but constraints and views refer to the table ID, not=20
the table name, so it's a real pain.  When I had to do this I ended up=20
just importing the database into 7.3, doing the operations, then=20
exporting the entire database back to 7.2.  But it's probably doable by=20
messing with the magic pg_ tables enough, and if it's hard that just=20
means it's better to encapsulate all that effort into a program. =20
Anyway, doing it with MySQL would be way easier.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
sqlobject-discuss mailing list
sql...@li...
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

RE: [SQLObject] ezSqlObject convenience wrapper

[<jws...@ra...>]

>This debate is becoming a pointless "yes it is", "no it isn't" sort of 
>thing though, and I can see now I won't be able to make headway on my 
>point, but my logic still stands. If everybody approached this 
>situation in the same way (e.g. Daniel with inheritance, Sidnei with 
>CASCADE and such), we'd have five or six "wrapper" packages like this 
>is no time.

One would hope that these extension would be test beds for new ideas and if
worthwhile, would eventually be mainstreamed. If there were multiple 
independent code forks, that should probably be interpreted as impatience
with the development speed of the main code. Having too many people 
contributing code is a problem every project should wish for.

Re: [SQLObject] ezSqlObject convenience wrapper

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

On Monday, March 8, 2004, at 12:53  AM, Ian Bicking wrote:

> On Mar 7, 2004, at 6:45 PM, Brad Bollenbach wrote:
>> On Sunday, March 7, 2004, at 07:23  PM, David McNab wrote:
>>
>>> Brad Bollenbach wrote:
>>>> It doesn't make any sense to create another module for this.
>>>
>>> I can't say I agree here.
>>>
>>> Wrapper modules are a great way to try out ideas.
>>>
>>> If the core package devs happen to like one or more of the ideas, 
>>> they can always merge them in, or give cvs write access to whover 
>>> wrote the wrapper.
>>>
>>> And if the core devs don't like the ideas, the wrapper writer gets 
>>> to use the wrapped interface in his/her code regardless.
>>>
>>> Nobody loses.
>>
>> Except those of us that don't want to needlessly have to track two 
>> codebases for no reason. :) By following your logic here, it wouldn't 
>> take much for us to suddenly have five or six different "wrapper" 
>> packages to "try out ideas".
>
> But it's a *wrapper*, not a fork.  A wrapper isn't a codebase to track 
> really -- except to the degree that it might use some private 
> interfaces or otherwise be sensitive to changes in the wrapped 
> package.  But that just means the wrapper is tied to a version, or the 
> author has to keep track of changes; it's not that big a deal.
>
> The wrapper is Good Enough for David.  If there are features that 
> other people really like in it, then certainly they can be moved to 
> the main SQLObject code (as long as those other people speak up).  
> Really, time will tell.

The only person who's used the term "fork" here is you. :)

It definitely is another codebase to track (install, import, then when 
the changes do finally get merged, uninstall, change the imports to be 
from where they belong, SQLObject, etc.), which assures that our 
projects that are using SQLObject (and have discovered a few important 
bugs along the way), won't be trying out these changes.

This debate is becoming a pointless "yes it is", "no it isn't" sort of 
thing though, and I can see now I won't be able to make headway on my 
point, but my logic still stands. If everybody approached this 
situation in the same way (e.g. Daniel with inheritance, Sidnei with 
CASCADE and such), we'd have five or six "wrapper" packages like this 
is no time.

--
Brad Bollenbach

Re: [SQLObject] ezSqlObject convenience wrapper

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

On Mar 7, 2004, at 6:45 PM, Brad Bollenbach wrote:
> On Sunday, March 7, 2004, at 07:23  PM, David McNab wrote:
>
>> Brad Bollenbach wrote:
>>> It doesn't make any sense to create another module for this.
>>
>> I can't say I agree here.
>>
>> Wrapper modules are a great way to try out ideas.
>>
>> If the core package devs happen to like one or more of the ideas, 
>> they can always merge them in, or give cvs write access to whover 
>> wrote the wrapper.
>>
>> And if the core devs don't like the ideas, the wrapper writer gets to 
>> use the wrapped interface in his/her code regardless.
>>
>> Nobody loses.
>
> Except those of us that don't want to needlessly have to track two 
> codebases for no reason. :) By following your logic here, it wouldn't 
> take much for us to suddenly have five or six different "wrapper" 
> packages to "try out ideas".

But it's a *wrapper*, not a fork.  A wrapper isn't a codebase to track 
really -- except to the degree that it might use some private 
interfaces or otherwise be sensitive to changes in the wrapped package. 
  But that just means the wrapper is tied to a version, or the author 
has to keep track of changes; it's not that big a deal.

The wrapper is Good Enough for David.  If there are features that other 
people really like in it, then certainly they can be moved to the main 
SQLObject code (as long as those other people speak up).  Really, time 
will tell.

>>> [number of columns perhaps?], but len() on a SelectResults is 
>>> already done by using the count() method on an instance.)
>>
>> len(something) is slightly more readable and convenient.
>
> As Ian mentioned, that was specifically removed from SQLObject a 
> little while back.

Right, but he wouldn't know that.  Anyway, I added this as a FAQ since 
it's actually come up a couple times since I made the change.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org

Re: [SQLObject] ezSqlObject convenience wrapper

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

On Sunday, March 7, 2004, at 07:23  PM, David McNab wrote:

> Brad Bollenbach wrote:
>> It doesn't make any sense to create another module for this.
>
> I can't say I agree here.
>
> Wrapper modules are a great way to try out ideas.
>
> If the core package devs happen to like one or more of the ideas, they 
> can always merge them in, or give cvs write access to whover wrote the 
> wrapper.
>
> And if the core devs don't like the ideas, the wrapper writer gets to 
> use the wrapped interface in his/her code regardless.
>
> Nobody loses.

Except those of us that don't want to needlessly have to track two 
codebases for no reason. :) By following your logic here, it wouldn't 
take much for us to suddenly have five or six different "wrapper" 
packages to "try out ideas".

We're talking about a bleeding edge source code repository here; 
patches truly are welcome. Your volunteer efforts are warmly received.

>> As well, some of these features don't make sense (e.g. I'm not sure 
>> what len() on a table is supposed to tell me
>
> len(sometable) simply returns the number of rows in the table.

Oh, I wouldn't have expected that, but that's an aside to the main 
issue.

>> [number of columns perhaps?], but len() on a SelectResults is already 
>> done by using the count() method on an instance.)
>
> len(something) is slightly more readable and convenient.

As Ian mentioned, that was specifically removed from SQLObject a little 
while back.

>> Just ask Ian for checkin privileges (if you don't already have), 
>> write unit tests to demonstrate how you want your new features to 
>> work, and add them and the code that passes those tests to SQLObject 
>> directly.
>
> I wouldn't presume to ask for the ability to maul someone else's 
> codebase when I've just drifted in off the net, I'm not known, and 
> there hasn't been time for a trust relationship to develop.

There's no better way to quickly establish a trust relationship than by 
having some unit tests and code that passes them ready to submit. :) At 
the least, you could pass it through one of the committers hands 
(myself included) to get us to merge it for you. If there's any concern 
about merging it with HEAD (or whatever svn calls HEAD), then we could 
just create a branch with those specific changes and wait until they've 
been tried and discussed enough to consider merging them into the HEAD.

Make no mistake, your volunteer time contributed to helping SQLObject 
is well received, I just think that putting your changes into a 
separate module is (for reasons already mentioned) a mistake.

--
Brad Bollenbach

Re: [SQLObject] ezSqlObject convenience wrapper

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

Brad Bollenbach wrote:
> It doesn't make any sense to create another module for this.

I can't say I agree here.

Wrapper modules are a great way to try out ideas.

If the core package devs happen to like one or more of the ideas, they 
can always merge them in, or give cvs write access to whover wrote the 
wrapper.

And if the core devs don't like the ideas, the wrapper writer gets to 
use the wrapped interface in his/her code regardless.

Nobody loses.

> As well, 
> some of these features don't make sense (e.g. I'm not sure what len() on 
> a table is supposed to tell me

len(sometable) simply returns the number of rows in the table.

> [number of columns perhaps?], but len() 
> on a SelectResults is already done by using the count() method on an 
> instance.)

len(something) is slightly more readable and convenient.

> Just ask Ian for checkin privileges (if you don't already have), write 
> unit tests to demonstrate how you want your new features to work, and 
> add them and the code that passes those tests to SQLObject directly.

I wouldn't presume to ask for the ability to maul someone else's 
codebase when I've just drifted in off the net, I'm not known, and there 
hasn't been time for a trust relationship to develop.

Cheers
David

--

leave this line intact so your email gets through my junk mail filter

Re: [SQLObject] Using SQLObjects without database actions.

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

On Mar 7, 2004, at 10:37 AM, Peter Gebauer wrote:
> Many times I want to use SQLObjects as regular data structures, fill 
> them
> with data and manipulate that data, but without having to save the 
> data to
> the backend. The best thing would be to have a switch in the SQLObject
> telling it when and when not to be database consious.
>
> Or, maybe a small add-on that will make a non-database conscious 
> object of
> an SQLObject and populate an SQLObject from a non-database concsious 
> object.
>
> Has anybody written anything like this already?

Luke Opperman was talking about this a while ago, and had experimented 
some with a MemoryConnection, which was like a fake database connection 
that just kept the values in memory.  Then if you add a 
copyToConnection method, you could copy from memory to the database 
when you were ready.

The complicated part, though, was IDs.  It's possible you'd want to 
associate other SQLObject instances with these memory objects, but you 
wouldn't know what their ultimate ID was going to be.

This is where the transaction stuff and lazy/batch updates in the 0.6 
plan come into play (though it might happen after 0.6) -- in that 
design, the transaction would keep track of dirty objects and update 
them all at once -- or not at all.  You'd preallocate IDs, because 
you'd already know what your target database was going to be.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org

Re: [SQLObject] Re: Using SQLObjects without database actions.

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

On Mar 7, 2004, at 12:47 PM, Chris Gahan wrote:
> "Peter Gebauer" <pe...@fs...> wrote in message
> news:20040307163700.GA1776@coke...
>> Many times I want to use SQLObjects as regular data structures, fill 
>> them
>> with data and manipulate that data, but without having to save the 
>> data to
>> the backend. The best thing would be to have a switch in the SQLObject
>> telling it when and when not to be database consious.
>>
>> Or, maybe a small add-on that will make a non-database conscious 
>> object of
>> an SQLObject and populate an SQLObject from a non-database concsious
> object.
>>
>> Has anybody written anything like this already?
>
> Well, what I did was add .acquireLock() and .releaseLock() functions 
> to the
> SQLObject subclass I made which would adjust and check the "locked" and
> "locktimeout" variables. Then I added a function to SQLObject.py called
> .values() which returns a dictionary of all the table attributes (it 
> gets
> the attributes the same way that .__repr__() does).
>
> It's not a very general purpose solution though. I like the idea of 
> having a
> kind of "update object" which looks like an SQLObject, and can be 
> shoved
> back into the database when it's finished being updated. It would be
> especially handy if it was picklable, so that it could be used as a 
> Webware
> session variable.
>
> Hmmm... Ian? What do you think? :)

It's pretty complicated when you start to think about it.  Some of the 
stuff I proposed for 0.6 is along these lines.  I've thought it through 
a few different ways, but I haven't felt comfortable about a real 
solution -- how to handle objects that aren't in the database yet, or 
aren't associated with a connection at all... how to deal with 
references among these objects... it's pretty challenging.

Pickleability is fairly reasonable right now (so long as you aren't 
using transactions, at which point pickle is unlikely to work 
conceptually -- at least until you have transactions that are more 
abstract than a DBAPI connection object).  Anyway, it's just a matter 
of implementing __getstate__ and __setstate__.  The only information 
you should need in the state is the ID and perhaps a connection 
identification, though you could leave out the connection in most cases 
(since the class will already have an associated connection).  The 
connection would be easier with SQLObject trunk, because we have URIs 
for connections that makes them pretty easy to identify and serialize.

Unfortunately, __setstate__ isn't really the API we'd like to have -- 
in that case we already have an instance and we need to put it into 
working order.  But we might already have an instance in the process, 
and we don't want to create another.  This is where 0.5 is easier, 
because we can just use __getinitargs__ -- I think it might be best to 
extend 0.6's __init__ so that (with the right invocation) it can act 
like 0.5's (i.e., get an object instead of creating a new object).

Anyway, pickle shouldn't be too hard.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org

Re: [SQLObject] ezSqlObject convenience wrapper

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

On dimanche, mars 7, 2004, at 15:44 Canada/Eastern, Ian Bicking wrote:

> On Mar 7, 2004, at 11:48 AM, Brad Bollenbach wrote:
>> On samedi, mars 6, 2004, at 03:17 Canada/Eastern, David McNab wrote:
>>> I've just put up a module called EzSqlObject, which wraps 
>>> SQLObject's connection, table and results classes, and adds a few 
>>> conveniences:
>>>
>>> *  .tables attribute in connection objects, lists out the tables in
>>>    the database
>>> *  .columns attribute in table objects, lists the columns in the 
>>> table
>>> *  automatic retrieval of existing table structure from database (if
>>>    not provided as a table class)
>>> *  tables of a database available as attributes of connection object
>>> *  Can fetch individual rows from a table or resultset via array 
>>> index
>>> *  automatic logging
>>> *  dump() method in connection, table and results objects
>>> *  len() works for table and results objects
>>> *  doQuery() method for connection objects
>>
>> It doesn't make any sense to create another module for this. As well, 
>> some of these features don't make sense (e.g. I'm not sure what len() 
>> on a table is supposed to tell me [number of columns perhaps?], but 
>> len() on a SelectResults is already done by using the count() method 
>> on an instance.)
>
> I actually specifically took out len() support, because it gets called 
> by list() and some other functions implicitly, causing unnecessary 
> database queries.
>
> I like wrappers myself, so it's cool by me if it's a separate module.  
> I think tables being attributes of the connection only works for a 
> certain set of applications, so I don't think it belongs as a general 
> SQLObject feature (though maybe, I'm not sure).

Sorry, but I'll have to say -1 on this.

Because of its frameworkish/libraryish nature, many of SQLObject's 
features will only apply to a certain set of applications (which is the 
case with basically any framework or library.)

This doesn't justify creating another codebase for what is just a few 
attribute and method additions.

--
Brad Bollenbach

Re: [SQLObject] ezSqlObject convenience wrapper

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

On Mar 7, 2004, at 11:48 AM, Brad Bollenbach wrote:
> On samedi, mars 6, 2004, at 03:17 Canada/Eastern, David McNab wrote:
>> I've just put up a module called EzSqlObject, which wraps SQLObject's 
>> connection, table and results classes, and adds a few conveniences:
>>
>> *  .tables attribute in connection objects, lists out the tables in
>>    the database
>> *  .columns attribute in table objects, lists the columns in the table
>> *  automatic retrieval of existing table structure from database (if
>>    not provided as a table class)
>> *  tables of a database available as attributes of connection object
>> *  Can fetch individual rows from a table or resultset via array index
>> *  automatic logging
>> *  dump() method in connection, table and results objects
>> *  len() works for table and results objects
>> *  doQuery() method for connection objects
>
> It doesn't make any sense to create another module for this. As well, 
> some of these features don't make sense (e.g. I'm not sure what len() 
> on a table is supposed to tell me [number of columns perhaps?], but 
> len() on a SelectResults is already done by using the count() method 
> on an instance.)

I actually specifically took out len() support, because it gets called 
by list() and some other functions implicitly, causing unnecessary 
database queries.

I like wrappers myself, so it's cool by me if it's a separate module.  
I think tables being attributes of the connection only works for a 
certain set of applications, so I don't think it belongs as a general 
SQLObject feature (though maybe, I'm not sure).

But yes, I'd be happy to have David add some of these features directly 
into SQLObject directly.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org

Re: [SQLObject] Re: Changing table structure via SQLOBject

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

On Mar 6, 2004, at 11:16 PM, Chris Gahan wrote:
> Hey, that reminds me... you know what I think would be cool?
>
> Well, probably not, so I'll tell you!
>
> A function that you can run after you've modified the attributes of an
> SQLObject which will update the database's table to add the new 
> attributes
> and changes WITHOUT requiring you to lose all of your data (or to have 
> to
> change the table by hand)!
>
> It would only work if you've made changes that aren't impossible to 
> convert
> (i.e. changing a StringCol() to an IntCol()). I think it would be 
> handy. :)
>
> Is there a clever way of implementing this, or is it basically just a 
> whole
> load of if statements....? (i.e. is there a facility in MySQL or 
> PostgreSQL
> which lets you submit a new schema and IT figures out if it's possible 
> to
> convert the table to that?)

There's a utility called (I think) mysqldiff which compares table 
definitions and comes up with a way to convert one to the other.  I 
believe it tries to keep values, though obviously it could be difficult 
(e.g., it can't tell that you meant to rename a column).  There's 
something like pgdiff (I'm kind of making up the names here) that does 
the same for Postgres, but I don't think it works as well -- Postgres 
still has a bunch of restrictions when it comes to altering tables 
(though 7.3 seems to remove several of these).

It would be an interesting task to do this with SQLObject, but I think 
it would actually be more like a SQLObject application than part of the 
library (though maybe not).  In many ways it would be easier than with 
these diff applications, because you could do it procedurally.  E.g., 
add the new column, copy all the values over using whatever kind of 
conversion function you want, then drop the old column, and maybe 
rename the new column.  Way easier than with the diff utilities, 
because it doesn't have to divine what changes you intended by looking 
at a description of the before and after state.

I know this all gets to be a pain in Postgres because of constraints.  
E.g., there's some recipes for deleting columns in 7.2 where you create 
the new table, copy all the values, then rename it so its in the old 
table's place -- but constraints and views refer to the table ID, not 
the table name, so it's a real pain.  When I had to do this I ended up 
just importing the database into 7.3, doing the operations, then 
exporting the entire database back to 7.2.  But it's probably doable by 
messing with the magic pg_ tables enough, and if it's hard that just 
means it's better to encapsulate all that effort into a program.  
Anyway, doing it with MySQL would be way easier.

--
Ian Bicking | ia...@co... | http://blog.ianbicking.org

[SQLObject] Re: Using SQLObjects without database actions.

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

"Peter Gebauer" <pe...@fs...> wrote in message
news:20040307163700.GA1776@coke...
> Many times I want to use SQLObjects as regular data structures, fill them
> with data and manipulate that data, but without having to save the data to
> the backend. The best thing would be to have a switch in the SQLObject
> telling it when and when not to be database consious.
>
> Or, maybe a small add-on that will make a non-database conscious object of
> an SQLObject and populate an SQLObject from a non-database concsious
object.
>
> Has anybody written anything like this already?

Well, what I did was add .acquireLock() and .releaseLock() functions to the
SQLObject subclass I made which would adjust and check the "locked" and
"locktimeout" variables. Then I added a function to SQLObject.py called
.values() which returns a dictionary of all the table attributes (it gets
the attributes the same way that .__repr__() does).

It's not a very general purpose solution though. I like the idea of having a
kind of "update object" which looks like an SQLObject, and can be shoved
back into the database when it's finished being updated. It would be
especially handy if it was picklable, so that it could be used as a Webware
session variable.

Hmmm... Ian? What do you think? :)

Re: [SQLObject] ezSqlObject convenience wrapper

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

On samedi, mars 6, 2004, at 03:17 Canada/Eastern, David McNab wrote:

> Hi,
>
> I've just put up a module called EzSqlObject, which wraps SQLObject's 
> connection, table and results classes, and adds a few conveniences:
>
> *  .tables attribute in connection objects, lists out the tables in
>    the database
> *  .columns attribute in table objects, lists the columns in the table
> *  automatic retrieval of existing table structure from database (if
>    not provided as a table class)
> *  tables of a database available as attributes of connection object
> *  Can fetch individual rows from a table or resultset via array index
> *  automatic logging
> *  dump() method in connection, table and results objects
> *  len() works for table and results objects
> *  doQuery() method for connection objects

It doesn't make any sense to create another module for this. As well, 
some of these features don't make sense (e.g. I'm not sure what len() 
on a table is supposed to tell me [number of columns perhaps?], but 
len() on a SelectResults is already done by using the count() method on 
an instance.)

Just ask Ian for checkin privileges (if you don't already have), write 
unit tests to demonstrate how you want your new features to work, and 
add them and the code that passes those tests to SQLObject directly.

--
Brad Bollenbach

[SQLObject] Using SQLObjects without database actions.

[Peter G. <pe...@fs...>]

Hey there!

Many times I want to use SQLObjects as regular data structures, fill them 
with data and manipulate that data, but without having to save the data to 
the backend. The best thing would be to have a switch in the SQLObject 
telling it when and when not to be database consious.

Or, maybe a small add-on that will make a non-database conscious object of 
an SQLObject and populate an SQLObject from a non-database concsious object.

Has anybody written anything like this already?

[SQLObject] Re: Changing table structure via SQLOBject

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

Uhm, just read my last post here... It's a little ambiguous.

"Chris Gahan" <ch...@il...> wrote in message
news:c2eb69$emk$1...@se......
> [...] you know what I think would be cool?
> A function that you can run after you've modified the attributes of an
> SQLObject which will update the database's table to add the new attributes
> and changes WITHOUT requiring you to lose all of your data (or to have to
> change the table by hand)!

By "modified the attributes", I mean "change the definition of an SQLObject
subclass", not "change the values of the attributes" :)

Here's an example... if my original definition was:

def SuperVillain(SQLObject):
  realname = StringCol()
  coolVillainName = StringCol()
  nicknameTauntedByInSchool = StringCol()

...and then I changed it thusly:

def SuperVillain(SQLObject):
  realname = StringCol()
  coolVillainName = StringCol()
  nicknameTauntedByInSchool = StringCol(default='Stupid')
  evilCatchphrase = EnumCol(enumValues=["You will all feel my wrath!", "None
can withstand my awesome power!", "Muahahahahaha!!"])

...and then ran the new (currently fictitious) function
"SuperVillain.updateTableSchema()", it would add an evil_catchphrase column.

Yeah. That's what I mean. :)

[SQLObject] Re: Changing table structure via SQLOBject

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

Hey, that reminds me... you know what I think would be cool?

Well, probably not, so I'll tell you!

A function that you can run after you've modified the attributes of an
SQLObject which will update the database's table to add the new attributes
and changes WITHOUT requiring you to lose all of your data (or to have to
change the table by hand)!

It would only work if you've made changes that aren't impossible to convert
(i.e. changing a StringCol() to an IntCol()). I think it would be handy. :)

Is there a clever way of implementing this, or is it basically just a whole
load of if statements....? (i.e. is there a facility in MySQL or PostgreSQL
which lets you submit a new schema and IT figures out if it's possible to
convert the table to that?)

"David McNab" <da...@re...> wrote in message
news:404...@re......
> Found it in the manual under 'Runtime Column Changes'.
>
> Sorry for the mailbox noise.
>
> David McNab wrote:
> > Hi,
> >
> > Is there any way to change the structure of a table via SQLObject? Or do
> > I need to fire off a raw query?
> >
> > I'm particularly interested in being able to add ForeignKey()s,
> > MultipleJoin()s etc.
> >
>
> -- 
>
> Kind regards
> David
>
> --
>
> leave this line intact so your email gets through my junk mail filter
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click

Re: [SQLObject] Changing table structure via SQLOBject

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

Found it in the manual under 'Runtime Column Changes'.

Sorry for the mailbox noise.

David McNab wrote:
> Hi,
> 
> Is there any way to change the structure of a table via SQLObject? Or do 
> I need to fire off a raw query?
> 
> I'm particularly interested in being able to add ForeignKey()s, 
> MultipleJoin()s etc.
> 

-- 

Kind regards
David

--

leave this line intact so your email gets through my junk mail filter

[SQLObject] Changing table structure via SQLOBject

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

Hi,

Is there any way to change the structure of a table via SQLObject? Or do 
I need to fire off a raw query?

I'm particularly interested in being able to add ForeignKey()s, 
MultipleJoin()s etc.

-- 

Kind regards
David

--

leave this line intact so your email gets through my junk mail filter