Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Object Database (ODBMS) for Python

Reply
Thread Tools

Re: Object Database (ODBMS) for Python

 
 
Patrick K. O'Brien
Guest
Posts: n/a
 
      08-30-2003
Jeremy Jones <(E-Mail Removed)> writes:

> On Fri, 29 Aug 2003 12:11:51 -0400
> "Paul D. Fernhout" <(E-Mail Removed)> wrote:
>
> > By the way, I like your overview of various related ODBMS projects
> > here: http://www.orbtech.com/wiki/PythonPersistence (maybe
> > http://munkware.sourceforge.net/ might go there now?)

>
> I wouldn't be offended if Munkware found its way to the
> PythonPersistence page


Me either. It's a wiki, so please feel free to add anything you like.

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
 
Reply With Quote
 
 
 
 
Paul D. Fernhout
Guest
Posts: n/a
 
      08-31-2003
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/documenta...gGuide-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! =-----
 
Reply With Quote
 
 
 
 
Patrick K. O'Brien
Guest
Posts: n/a
 
      09-01-2003
"Paul D. Fernhout" <(E-Mail Removed)> writes:

> 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.
>

[Analogy snipped]
>


Your analogy is absolutely correct. A PyPerSyst transaction
Class/instance follows the Command pattern. In fact, they were
initial called commands, and later renamed to transactions to
emphasize the fact that the actions taking place inside the command
needed to be atomic and leave the database in a consistent state (half
of the ACID properties needed to be a reliable database). PyPerSyst
itself provides the isolation (the engine provides this) and
durability (storage provides this).

> 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.


Yes! And I love how you describe this - random flounderings.

> 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.


Absolutely. And I'm glad you like it. Now if only I had a perfect
model for guaranteeing the integrity and consistency of the state of
Python class instances, we'd be set. Well, actually, I've got some
ways to do that, I just don't completely like them.

> 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...)


I'm not sure we'd be able to easily support undo and redo in a
multi-user environment. For a single-user application, this should be
easy. And I'll probably eventually build in mechanisms to support
this. But multi-user adds a few complexities.

Commit and rollback would be nice for complex transactions that change
a lot of state where your ability to guarantee the success of those
changes, or test the success as a pre-condition, is difficult. The
easiest approach, which Prevayler is implementing, is to always have
two copies of the database in memory - one to try out a transaction
and see if it completes, the other to receive only transactions that
successfully completed on the tester. But that approach doubles the
memory requirements, and we already have high memory requirements
since we keep the entire object graph in memory. But the beauty of
this approach is that it is simple and foolproof.

Another approach would be for each transaction to keep mementos of
objects that get changed, so they can be restored if an exception is
raised at some point during the transaction. But I think that will be
too complex and too much to expect from transaction writers, unless I
can come up with support for that in PyPerSyst that makes it easier.

Anyway, just some more thoughts. Good talking to you.

--
Patrick K. O'Brien
Orbtech http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Database Database Database Database scott93727@gmail.com Computer Information 0 09-27-2012 02:43 AM
DataBase DataBase DataBase DataBase scott93727@gmail.com Computer Information 0 09-26-2012 09:40 AM
Object creation - Do we really need to create a parent for a derieved object - can't the base object just point to an already created base object jon wayne C++ 9 09-22-2005 02:06 AM
Re: Object Database (ODBMS) for Python Niki Spahiev Python 2 09-01-2003 08:44 PM
Object Database (ODBMS) for Python Patrick K. O'Brien Python 0 08-28-2003 09:37 PM



Advertisments