Thread: Re: [SQLObject] ezSqlObject convenience wrapper
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
Menu
▾
▴
sqlobject-discuss
|
From: Brad B. <br...@bb...> - 2004-03-07 18:07:43
|
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 |
|
From: Brad B. <br...@bb...> - 2004-03-07 21:26:38
|
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 |
|
From: Brad B. <br...@bb...> - 2004-03-08 01:04:42
|
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 |
|
From: Ian B. <ia...@co...> - 2004-03-08 06:09:54
|
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 |
|
From: Brad B. <br...@bb...> - 2004-03-08 13:45:03
|
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 |
|
From: <jws...@ra...> - 2004-03-08 14:07:02
|
>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. |
|
From: Brad B. <br...@bb...> - 2004-03-08 19:11:55
|
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 |
|
From: Ian B. <ia...@co...> - 2004-03-08 21:50:53
|
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 |
|
From: Brad B. <br...@bb...> - 2004-03-08 22:27:16
|
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 |
|
From: Ian B. <ia...@co...> - 2004-03-07 21:00:31
|
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 |
|
From: David M. <da...@re...> - 2004-03-08 00:39:59
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X