Has anyone used SQLDict or the newer SQLORB from Andy Dustman? I'm using
SQLDict with some of my own modifications for caching and thread safety
(as well as custom functions to simulate relationships).
Ian, have you used either of these and, if so, how would you compare
yours to what Andy wrote?
Thanks,
Tracy
Tue, 22 Oct 2002 01:47:32 -0500
>(Since I was writing this up I thought I might as well copy it to DB-SIG
>as well)
>
>On Tue, 2002-10-22 at 00:51, Steve Freitas wrote:
>> Could you illuminate for us the differences in
>> philosophy and applicability between SQLObject and MiddleKit?
>
>SQLObject and MiddleKit are basically trying to do the same thing --
>both cache similarly, for instance, and neither deals with
>transactions. I think MK has some sense of committing changes -- I
>can't remember -- but SQLObject currently commits all changes
>immediately. But for the most part when using the objects (as opposed
>to defining them), MK and SQLObject should feel fairly similar -- the
>differences are more syntactic than semantic.
>
>I can't claim I ever really committed to using MK -- I played with it
>some, but that's all. But I did make SQLObject somewhat in response.
>
>I didn't like the way objects were defined in MK -- CSV files bug me,
>and in general I like Python and want to stick to Python. So you define
>the objects (table and column names, etc) just with some special class
>attributes. It uses some Python magic (metaclasses) to turn those into
>a fully-functional class definition. In contrast, MK uses code
>generation to pretty much the same effect. And my vague impression is
>that PyDO avoids all this trouble by using the dictionary interface, so
>it doesn't have to create methods for each column -- I specifically
>didn't want to do something like that, because I don't want the database
>columns to be distinguishable from other methods and attributes. Making
>that distinction, IMHO, is a significant compromise of the whole point
>of a middle object.
>
>Both SQLObject and MK should perform relatively similarly. SQLObject
>may be faster in some aspects (less function calls, for instance), but I
>would not be surprised if this difference was negligible.
>
>SQLObject does not do any data integrity checks, unlike MK. But you can
>use subclassing to do your own checks, just like in MK. In effect, you
>won't automatically catch a column being set to a non-integers despite
>its definition. In practice, SQL handles 10 just like '10', and gives
>the necessary errors if you pass a string that can't be coerced into an
>integer, so I wasn't very concerned. True error checking in both cases
>requires custom code (assuming your constraints aren't trivial). I
>suppose in more powerful databases you can use constraints in the
>database -- but again, that's up to you (as it should be).
>
>MK does schema generation. SQLObject deliberately does not; schema
>generation just didn't seem like a problem in need of solving to me. I
>also want to make as few requirements on the schema as possible.
>
>Both MK and SQLObject currently only work with MySQL. I hope to extend
>SQLObject, and I think it should be very easy (actually, I hope others
>will extend it, but I'll help them :). There's really only one part of
>SQLObject that need to be ported -- inserting a row, to be specific.
>
>SQLObject has an experimental feature for selecting multiple objects
>(i.e., generating a SELECT statement). I think it's clever and cute --
>I'm not actually sure how useful it is.
>
>SQLObject also happens to use properties, as introduced in Python 2.2.
>Mostly because this is my first 2.2-specific code, and I thought I'd go
>all out. So you do things like "p.firstName" and "p.firstName = 'Joe'"
>instead of "p.firstName()" and "p.setFirstName('Joe')" like you would in
>MK.
>
>I think that's a fairly thorough explanation. MiddleKit is more mature,
>of course, and has thorough unit tests and all that good stuff. When
>you are actually using them, I think you'll find SQLObject is less
>formal and easier to experiment with. I wanted it to feel thinner,
>which I think it does. (It's also small enough that I don't feel
>entirely crazy when I fantasize about it becoming simply Correct, tests
>or no tests -- but it's not there yet, of course :)
>
> Ian
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
