Object Database (ODBMS) for Python

[Paul D. Fernhout]

Patrick-

I think based on this and your other posts I now understand better where 
you are coming from. Thanks for the explainations and comments.

To try to restate (and better justify) what I now think I see as your 
point of view on this transactional API issue, let me present this analogy.

When one builds a modern GUI application that supports complete 
multicommand "Undo" and "Redo" such as built on the Macintosh MacApp 
framework
http://developer.apple.com/documentation/mac/MacAppProgGuide/MacAppProgGuide-44.html
or any other similar approach, the stategy generally is to have a stack 
of Command (subclassed) objects, where each such object supports "do", 
"undo" and "redo". We use a general purpose system like this for example 
in our Garden Simulator software (and other Delphi applications -- 
hopefully someday to be ported to Python).
   http://www.gardenwithinsight.com/progmanlong.htm
Rather than mess with the application's data domain directly, every user 
action in such an undoable application, from selecting an object in a 
drawing program, to making a change with a slider, to dragging an 
object, to deleting an item, to even setting multiple options in a 
dialog (if each change isn't itself a command), creates a command (i.e. 
a transaction), which changes the domain and then continues to modify 
the domain while it is active (say at the top of the command stack while 
a mouse is dragged) and then completely finishes modifying the domain 
and is left on the stack when all the related GUI activity is done. 
While the command (transaction) itself may fiddle with the domain, no 
button press, or mouse click, or drop down selection ever messes 
directly with the data domain (or what might in another context be sort 
of like the business logic and business data). By constraining changes 
to this approach, one can readily do, undo, and redo a stack of commands 
to one's heart's content -- and subject to available memory :-) or other 
limits.

Your transaction notion in PyPerSyst, now that I understand it better, 
seems to have something of this GUI command system flavor. And that 
emphasis is perhaps why you do not feel it is inconsistent to have one 
way to read values and another way to change values, since changing 
values is something in this model requiring significant forethought as 
an application level transaction. Implicitely, what you are getting at 
here is a development methodology where all data domain changes go 
through transactions (commands), and the transactions have been 
consciously considered and designed (rather than just resulting from 
randomly poking around in the data domain). And that is perhaps why you 
are so against the implicit transactions -- they violate this 
development methodology of being explicit about what chunks of changes 
are a transaction (as an atomic unit).  The same sort of issues come up 
whan people try to avoid COmmand type framekworks, thinking it is easier 
to just fire off changes directly to the data domain from GUI events 
(and it is easier -- just not undoable or consistent). Adhering to a 
transactional (command-al?) development methodology makes it very 
straightforward to understand how the application is structured and what 
it can or cannot do (i.e just look in the transaction (or command) class 
hierarchy). And so, from your perspective, it is quite reasonable to 
have a lot of work go into crafting transaction objects (or subclassing 
them from related ones etc.) in the same way that it is expected that 
GUI applications with undo/redo capabilities will have a lot of effort 
put into their analogous "Command" class hierarchy.

To step back a minute, in general, a transactional development 
methodology is in a way a step up from the random flounderings of how 
many programs work, with code that changes the data domain potentially 
sprinkled throughout the application code based, rather than cleanly 
specified in a set of Command or Transaction subclasses. So you are sort 
of proposing generally a step up in people's understanding and practice 
of how to deal with applications and persistent data.

Does this sort of capture an essential part of what you are getting at 
here with your PyPerSyst application architecture development strategy? 
If so, I like it. ;-)

All the best.

--Paul Fernhout
http://www.pointrel.org

P.S. The Pointrel System supports abandoning in process transactions by 
sotrign all the data it changes long the way, and being able to roll 
back to this state. But, with an object database as you have outlined 
it, I think this would naturally be a lot more complicated -- although 
perhaps you could adopt the "undo" and "redo" aspect of Commands 
(including stashing the old objects somewhere in case of a redo...)

Patrick K. O'Brien wrote:
[Lots of good stuff snipped, and thanks for the interesting dialogue. :-)]
 > If users expect symmetry it is because they are used to writing single
 > process programs that do not share objects.  Does anyone expect this
 > kind of symmetry and transparency when writing a multi-threaded
 > application?  Why not?  Granted, having start/end transaction
 > semantics might change some of the rules.  But even if we had those in
 > PyPerSyst, I would probably only use them inside of Transaction
 > classes, not embedded in application code where they are harder to
 > find and test.  Explicit transaction objects have many benefits.
 >
 > It's sort of similar to the notion of separating your application
 > logic from your gui code.  Sure its easier to just put a bunch of code
 > in the event handler for a button.  But is that the best way to code?
 > In my mind, implicit transactions, or commit/rollback in application
 > code, is like putting all your business logic in the event handlers
 > for your gui widgets.  I'm trying to keep people from writing crappy
 > persistent applications.

 >>I think this is the core of the question of this part of the thread.
 >>You wrote "I've come to think otherwise". I'd be curious to hear
 >>more on any use cases or examples on why transaparency is not so
 >>compatible with reliability etc.
 >
 > I just think implicit transparent transactions would lull users into a
 > false sense of integrity and make them write sloppy applications that
 > didn't actually maintain the integrity of their objects when used in a
 > multi-user environment.  I think the kind of applications I want to
 > use PyPerSyst for demand that it be difficult for application
 > programmers to do the wrong thing with regards to the integrity of the
 > persisted data.  I think having transactions as explicit objects
 > provides more control over the integrity of the database.  If users
 > want transparency, it can be done, using PyPerSyst, it just isn't the
 > focus of my current efforts.  And I don't think explicit transactions
 > are that much of a burden.  Transaction code is a small percentage of
 > application code, compared to all the interface code you have to
 > write.  And you could easily write wrappers for transactions that make
 > them less burdensome.



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 100,000 Newsgroups - 19 Different Servers! =-----