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 >
