Re: [SQLObject] Temporary Objects (I'm going in!)
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Brad B. <br...@bb...> - 2003-04-30 00:39:48
|
On 04/29/03 17:42, Luke Opperman wrote: > > > > I think t.insertObject(c) isn't a good idea. Client(1) is an > > object > > that may be in use in several places, and is presumed to be > > transparently persistent. When you put it into the transaction > > you've > > made temporary for all users of the object. Bad bugs will follow. > > At > > least in threaded situations. > > > > This is why I think the object has to be instantiated as part of > > the > > transaction, or perhaps copied if you don't like instantiation... > > > > t = Transaction() > > c = Client(1) > > ctmp = c.inTransaction(t) > > # or... > > ctmp = Client(1, t) > > > > Ian > > > > I couldn't agree more, this is also refers to the challenges (from an > interface perspective) of "insertObject" for new objects. Hence my > semantics note, "a temporary object (including one in Transaction: > i'm considering transactions to be a simple wrapper around a > temporary object implementation) is not visible to anything that > doesn't explicitly reference the python-side instance of it". This is > also why it seems to me that any Real objects referenced by or to a > temp object need to immediately become temp (part of the > transaction). > > My original interface suggestion is very close to what you just wrote, > with cInst.temp() or cClass.temp(...) returning temporary objects, > outside of being referenced by any other thread unless explicitly > passed by the programmer. > > Anyways, all just wanking until something gets built. :) I'll get on > it. Disclaimer: The answers I'm giving are half-finished, really. I can't say either one is particularly satisfactory, but hopefully someone else will have a few more ideas to add to, and hopefully simplify the mix. Personally, I see many issues to flesh out here yet, and preserve the goal of keeping SQLObject painfully simple to use. Ease-of-use is the reason I switched from Modeling to SQLObject to begin with. The problem is: i. how can SQLObject be transactional? ii. should SQLObject be transactional (or should it be left to using the chosen backend to support it)? There's two main answers that I can see, so far. 1. To be like the Modeling framework, and use the Transaction metaphor, where Modeling uses an EditingContext: http://modeling.sourceforge.net/UserGuide/editing-context.html This adds one more level of indirection between Python objects and database persistence, as the only realistic way for this to be useful and thread-safe is for all data manipulation and retrieval to be done through a Transaction object, which will have a global registry of object ID's for the thread-safety end of things. I already gave an example of what the interface might look like here. SQLObject would still maintain the advantage of being less verbose than Modeling (e.g. new-style properties instead of get/set methods for every column like Modeling, no FetchSpecification like Modeling has, no need to edit a fancy XML file, etc.), but would unavoidably become slightly more complex to learn and use. 2. Scarecrow objects (the "temp" metaphor, except to me "temp" makes it difficult to extrapolate what that's supposed to mean IMHO). So you have: Client(1) to retrieve Client.new(name = "Somebody") to create Client.scarecrow() to create a "brainless" (database-dumb) object The Transaction metaphor could live behind the scenes of a scarecrow, so that scarecrow objects aren't truly persisted, but it's made note of by an object registry of some sort, so: from invoicing import Client ian = Client(1) luke = Client.new(name = "luke") brad = Client.scarecrow(name = "brad") sqlobject_geeks = Client.select('all') Assuming there was only a client with ID 1 in the database to begin with, sqlobject_geeks would now have all three of us in the list. The metaphor for rolling back and committing could be something like: if confirmed_signup: brad.remember() # "commit" the changes to brad else: brad.forget() # "rollback" the changes to brad Of course, this isn't very useful for atomocity. :/ The "temp" or "scarecrow" object (e.g. a single object "transaction") is probably better solved with lazy committing and a save() method needing to be called. Really though, I don't think I see adding a whole new class and metaphor to the framework for this "single object transaction" to be useful. Just my $0.02. -- Brad Bollenbach BBnet.ca |