Hi Jonathan

 

If you are interested in OmniBase on Pharo, there was a port by Sebastian 
Sastre in about 2010, which was forked and updated by Esteban Lorenzano in June 
2018 (https://github.com/estebanlm/OmniBase). There were a few bugs in the 
port, which were sorted out by Matias Maretto, ma...@omeleon.de 
<mailto:ma...@omeleon.de>  and myself. I have all these corrections in my local 
repo, but they have never been ported back to Esteban’s github repo, because I 
don’t know how to do it. So do not use Esteban’s repo until updated.

Esteban’s port was for Pharo 6, and in the case of marco and me was only tried 
on 32 bits. If you decided to install on 64-bit Pharo 7, you would be on new 
territory. The only problems are likely to be interactions with the file 
system. As a quick test, I installed Omnibase and tests in 32-bit Pharo 7. One 
test (#testBTreeKeyLocking) was red, all the rest green – I have not yet traced 
the cause. 

The biggest problem is likely to be documentation. I have tried only the 
simplest uses, because that is all I can work out from the slide-show notes. 
Maybe someone else who has used it more extensively might still have fuller 
documentation – e.g. Bruno, who also contributed to this thread.

 

Peter Kenny

 

 

 

From: Pharo-users <pharo-users-boun...@lists.pharo.org> On Behalf Of Jonathan 
van Alteren
Sent: 10 October 2019 11:39
To: Any question about pharo is welcome <pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] voyage mongo and transactionality

 

Hi Peter, 

 

Thanks for your reply.

 

That sounds very interesting. For similar reasons, I tried to check out Magma. 
However, since I'm still a novice in Pharo/Smalltalk and it's not very well 
documented (and mostly refers to Squeak), it's quite painful to figure out how 
it works and how to get it going in Pharo. Not to mention actually using it in 
production for an 'enterprise' application for an actual customer... I haven't 
given that up yet, but currently don't have the time.

 

I will look into OmniBase. Anything you're willing to share about getting it up 
and running (in Pharo 7.0 64-bit) is greatly appreciated!

 

 

Kind regards,

Jonathan van Alteren

Founding Member | Object Guild
jvalte...@objectguild.com <mailto:jvalte...@objectguild.com> 

On 9 Oct 2019, 20:34 +0200, PBKResearch <pe...@pbkresearch.co.uk 
<mailto:pe...@pbkresearch.co.uk> >, wrote:



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> 
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 < <mailto:pharo-users-boun...@lists.pharo.org> 
pharo-users-boun...@lists.pharo.org> On Behalf Of Norbert Hartl
Sent: 09 October 2019 18:08
To: Any question about pharo is welcome < <mailto:pharo-users@lists.pharo.org> 
pharo-users@lists.pharo.org>
Subject: Re: [Pharo-users] voyage mongo and transactionality

 

 


Am 09.10.2019 um 16:48 schrieb " <mailto:jtuc...@objektfabrik.de> 
jtuc...@objektfabrik.de" < <mailto:jtuc...@objektfabrik.de> 
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 Tuchel          mailto:jtuc...@objektfabrik.de
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1
 
 

Reply via email to