It may be irrelevant, but I have been playing recently with OmniBase,
which is a fully object-oriented database system, now over 20 years
old, but it still works very well for my uses. David Gorišek, the
author, claims that it has ACID properties. From my reading, updates
operate on a proxy object, which is not written to the database until
an explicit commit is given. A second transaction accessing the same
object will still see the original until the change is committed. What
happens to a proxy which is never committed is not clear, but if
Gorišek is right, the stored data can never be contaminated. I think a
proxy in this sense is equivalent to a memento.
Thanks to Esteban Lorenzano, OmniBase is now available on Pharo. The
code is ancient, there is no documentation and obviously no support,
but it might be worth while for someone to try some software
archaeology and put it to use. I have found it possible to create and
maintain a small database of natural language information, and access
is fairly quick and easy – and it’s all Smalltalk.
It claims to store all kinds of Smalltalk objects, except block
closures, and skimming through the code it seems to incorporate a
serializer similar to Fuel.
The only documentation I have found is a slideshow at
https://www.slideshare.net/esug/omni-baseobjectdatabase. I have found
out a few things about it, if anyone is interested.
Peter Kenny
*From:*Pharo-users <pharo-users-boun...@lists.pharo.org> *On Behalf Of
*Norbert Hartl
*Sent:* 09 October 2019 18:08
*To:* Any question about pharo is welcome <pharo-users@lists.pharo.org>
*Subject:* Re: [Pharo-users] voyage mongo and transactionality
Am 09.10.2019 um 16:48 schrieb "jtuc...@objektfabrik.de
<mailto:jtuc...@objektfabrik.de>" <jtuc...@objektfabrik.de
<mailto:jtuc...@objektfabrik.de>>:
This is a tricky mine field. Sometimes you need a lot of business
functionality in objects referenced in your objects that are
currently in the editor. So I'm still to see a project in which
the memento pattern really worked for more complex scenarios. How
deep do you dive to have enough memento objects to provide the
functionality needed. I guess you can do that with some sort of
object-level transaction framework that automatically creates
mementos of whatever object is being navigated to during some kind
of processing-context. I guess slots could be of use here. But
this is not trivial for general cases.
Yes it is tricky. You can have copies of business objects but you have
always references to the business objects not pointing to the copy.
And you need to know which objects should be tracked. In Gemstone IIRC
it is easy as it is the time the object is copied from the stone to
the gem it is registered in the current transaction. So you can check
it and committing if it changed because you have to write it back. The
important point here might be get noticed when a reference is
acquired. In pharo it is not that easy but could be done if object
would be reified and interceptable.
In my experience, this problem area makes for the other 70% of the
time spent on developing GUI or Web applications, besides the 60%
for GUI design and implementation and 25% business logic...
70% + 60% + 25% + 30% = 185%
sounds indeed very realistic if it comes to project planning. 😛There
is even a rule saying that for the first 90% of the project you need
the first 90% of time and for the last 10% of the project you need the
second 90% of time.
I'd be interested to learn about patterns to handle such more
complex things. We constantly travel back and forth between
implementing stuff in the GUI handlers (copying values to the GUI
classes that access themselves during GUI operations and push
values to the business objects when the users clicks on OK), using
mementos (which most of the times are nets of mementos that are
created manually - "we know what we'll touch in this Editor") and
operating on business objects directly and relying on the
persistence mechanism (Glorp in our case) and its rollback
behaviour. All three have lots of weaknesses and seem to have
their place nevertheless.
So this is a very interesting discussion and I think this is an
area that has not been solved yet.
I think it isn‘t solved and I find every piece of information about it
very interesting.
Norbert
Joachim
Am 09.10.19 um 16:25 schrieb James Foster:
Thanks for the explanation. And, yes, this is an artifact of
your design; if you put intermediate values into domain
objects then they will remain in your domain objects to be
seen later. >From what you’ve described, I don’t see how it
would be any different in a non-image environment (Java, C#,
etc.), unless you re-read the entire object graph from the
database. As someone else mentioned, this would be a good
place for the Memento Pattern.
James
On Oct 9, 2019, at 1:59 AM, Jonathan van Alteren
<jvalte...@objectguild.com
<mailto:jvalte...@objectguild.com>> wrote:
Hi James,
I see how my explanation might be unclear.
We have a main form for the agenda and a subform for an
item, which is shown using Seaside call/answer. The save
button of the subform is clicked, which adds the item to
the underlying agenda model object, but the save button of
the main form _is not_ clicked by the user. The callback
for the main save button sends the save message to the
agenda object, causing the database to be updated.
So yes, the browser does submit the data on the subform,
it's the main form component that doesn't receive the save
button callback. I realize that this is in large part an
issue with our design. However, the way object persistence
seems to work in the image environment plays a large role.
Kind regards,
Jonathan van Alteren
Founding Member | Object Guild
jvalte...@objectguild.com <mailto:jvalte...@objectguild.com>
On 8 Oct 2019, 15:41 +0200, James Foster
<smallt...@jgfoster.net <mailto:smallt...@jgfoster.net>>,
wrote:
On Oct 8, 2019, at 3:05 AM, Jonathan van Alteren
<jvalte...@objectguild.com
<mailto:jvalte...@objectguild.com>> wrote:
We've encountered an issue where a user makes
changes to an agenda, but does not click the Save
button. Instead, the user closes the browser or
uses the navigation to go to a different part of
the application. When navigating back to the
original agenda, the changes made previously (e.g.
items added) are still being displayed, even
though they were never explicitly saved.
Here is what I don’t understand: how did the change
get from the user’s client agent (browser) to the
server? If you make a change to a field in a form and
then close the browser, who sent the change to the
server? If you show the save domain value in a
different location, with a dynamically-generated id
and name (so it isn’t cached in the browser), or
written to the Pharo Transcript, does the value still
change? That is, are you sure that the change is in
the reflected in the Smalltalk image and not just
somehow cached in the browser?
James
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchelmailto:jtuc...@objektfabrik.de
Fliederweg 1http://www.objektfabrik.de
D-71640 Ludwigsburghttp://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
