Hi Estaban, Thanks for your feedback.
I agree that there might not be any real problem with Voyage. And yes, I think it was some kind of in-memory transaction handling that is was looking for. Can you explain a bit more about how the cache in Voyage works and why it is the way it is? The application in question doesn't have a lot of users, so changes are we could do without caching and still have good performance. I was used to working with JPA/Hibernate in Java, which doesn't seem to have the issue that we run into. Any idea why it works differently with Voyage/MongoDB? Is that because MongoDB doesn't support database transactions, hence missing a good trigger to flush the cache? Making copies of domain model objects somehow 'feels wrong'. When I have a person in my CRM domain, I feel strongly that it should always ever be represented by 1 object instance of class Person. The search continues... :-) Kind regards, Jonathan van Alteren Founding Member | Object Guild jvalte...@objectguild.com On 8 Oct 2019, 12:54 +0200, Esteban Lorenzano <esteba...@gmail.com>, wrote: > Hi, > > That looks a lot more like a Seaside mishandling than a problem with Voyage > itself. > > > On 8 Oct 2019, at 12:05, Jonathan van Alteren <jvalte...@objectguild.com> > > wrote: > > > > Hello all, > > > > We are having some issues with using Voyage/Mongo for a customer project > > that I'd like to get your feedback on. > > > > The customer application is a form based business web application using > > Seaside with object persistence using Voyage with MongoDB on Pharo 7.0. The > > application is deployed on a dedicated Linux production server running > > MongoDB version 4.2. > > > > The application is used to manage meeting agendas and minutes. After > > opening the agenda view of a future meeting, the user can add an item to > > the agenda by clicking a button. This calls an item editor component which > > answers when a Save or Cancel button is clicked. The agenda view component > > itself also has a Save button, which performs a Voyage save of the object > > aggregate (agenda + items). > > > > 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. > > > > It does not matter if we select the agenda aggregate object instance using > > Voyage or access it in a different way. Changes to the state of the object > > are retained, even though a Voyage save was never sent to the agenda > > instance. The cause seems to be that the Voyage repository caches the > > object instance and thus on select, it returns an object that is in a > > different state than how it was persisted. > > > > This all seems to come down to object transactionality. > > > > We have a need to 'cancel' changes made to an object instance. Before > > working with Pharo/Smalltalk in a non-image based environment, I was used > > to do this by retrieving the original object from persistence again. This > > also allowed for a convenient way to detect changes to an object's state, > > which we are missing at the moment too. > > In Voyage, new objects are just persisted (hence they enter the cache) once > you do the first “save”. > Retrieved objects are indeed in the cache, and since there is just one copy > for Pharo instance, if you do an update of a property (even if you do not > save), the cached instance will have the new attribute value, since there is > no in-memory transaction handling in Voyage. > > Which means: you need to handle it by your self. One solution is to work on a > copy and on “save” flush the changes before (it is easy to develop methods to > automatise this). > > Well, something like that :) > > > > > We know that moving to GemStone can help us with these issues, but our > > current planning of customer projects does not allow us to do this within > > the next 3 months. And we really need to find a way to tackle these issues . > > Well, not really, you will still need to copy modified values, retrieve new > and apply your changes. > Of course if you want to discard possible in-memory changes, yes, you can > cancel the transaction in gemstone… and you can also re-read the object in > Voyage (no special api for that, even if we could add it… you need to > re-execute a query for it). > > Esteban > > > > > > > Your feedback is greatly appreciated! > > > > > > > > Kind regards, > > > > > > Jonathan van Alteren > > > > Founding Member | Object Guild > > jvalte...@objectguild.com > > > >
