On 17 Apr 2014, at 16:26, Norbert Hartl <norb...@hartl.name> wrote: > > Am 17.04.2014 um 15:52 schrieb Sabine Knöfel <sabine.knoe...@gmail.com>: > >> Hi Norbert, >> >> for me the gain within smalltalk is huge because I want to navigate from >> person to trip and from trip to person by the attributes without asking >> mongo for the correspondent object via indexes. >> >> Don't you think that this is a question of design of the object model and >> should not be decided by database arguments? >> > I think there isn’t only one _or_ the other. Of course it is a lot more > beautiful to have set up proper objects and collections and do everything in > a smalltalkish way. That does only count as long as you stay on the island > (smalltalk image). As soon as you start to play with the outer world you have > to change your rules. If you agree it isn’t perfectly beautiful if you have a > proper object model that freezes your image, right? :) > IMHO the beauty comes from a mixture of both that fit them together without > restricting one or the other. > > So I would try to avoid storing both directions. But which one to skip? If I > assume that a person can have a lot of trips than I would skip the collection > inside Person. The more trips a Person has the bigger the serialized document > becomes. This makes it first slower to operate on the database and will fail > if you reach a document size of 16MB because that is the maximum Mongo > supports. Most of the time this will be a non-issue but for now I take it > into account. > So the data model will have a class Trip with an instVar pointing to Person. > And Person will have an instVar trips that is transient (see > VOMongoTransientDescription). The implementation for Person then goes > > Person>>#trips > ^ trips ifNil: [ trips := self fetchTrips ] > > Person>>#fetchTrips > ^ Trips selectMany: [: each| … ] > > Person>>#addTrip: aTrip > aTrip person: self. > aTrip save > > So the Trip will have a reference to Person in the database but Person will > have no reference to Trip. Person will retrieve its trips as soon as they are > used in a really smalltalkish way :). Person acts as a smalltalk object and > as a database object cache at the same time. > So this an implementation of Person that on the inside takes the database > nature in regard but on the outside the interface is pure smalltalk. > > Still not good?
yes, no good :) I mean: I understand there are times when you need it, but I would prefer a framework to solve that for me (then I can think just in my objects). And if the framework does not do a good job, then is a bad framework (even if made by me :P) and it needs to be improved. having to think in persistence is a cancer that needs to be removed :P Esteban > > Norbert > > >> Regards >> Sabine >> >> >> On Thu, Apr 17, 2014 at 3:40 PM, NorbertHartl [via Smalltalk] <[hidden >> email]> wrote: >> Sabine, >> >> I read the case now the first time. Just one note. Having references in both >> directions is probably not the best idea if using a non-object store. For >> navigating the graph it might be good but for persisting it is not. The >> serialization is a lot more complex if you do and the gain is nothing. For >> most databases with proper indexes you can request both directions easily >> and fast. So having one reference pointing from A to B you get the opposite >> direction for free. >> >> Norbert >> >> Am 17.04.2014 um 15:22 schrieb Sabine Knöfel <[hidden email]>: >> >>> Hi Olivier, >>> >>> possibly the option >>> VOMongoContainer>>enableMissingContent; >>> is useful to avoid >>> http://forum.world.st/Voyage-image-freeze-VOMongoError-Lazy-reference-not-found-td4703739.html >>> >>> Here is an example: >>> http://esug.org/data/ESUG2013/4-Thu/03-ESUG2013%20-%20VoyageTutorial.pdf >>> >>> Regards >>> Sabine >>> >>> >>> >>> >>> On Thu, Apr 17, 2014 at 3:07 PM, Olivier Auverlot [via Smalltalk] <<a >>> href="x-msg://56/user/SendEmail.jtp?type=node&node=4755097&i=0" >>> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >>> thanks Robert for the explications. >>> >>> I agree with you that's the best way to remove a book is to delete the >>> reference in ComicsCollection. >>> >>> But how to do that ? Must I simply remove the reference in the ordered >>> collection ? Voyage will syncronize automatically the data in memory with >>> the content of the database ? Must I force the save of the data after >>> removing the reference ? >>> >>> Olivier ;-) >>> >>> >>> 2014-04-17 14:10 GMT+02:00 Norbert Hartl <[hidden email]>: >>> >>> >>> Am 17.04.2014 um 13:53 schrieb olivier <[hidden email]>: >>> >>> > Hi, >>> > >>> > I'm using Voyage in a Pharo application. >>> > >>> > I have two MongoDB collections which are ComicsCollection and ComicsBook. >>> > Each book is attached to a instance of ComicsCollection. The reference of >>> > each book is stored in an ordered collection (in the instance of >>> > ComicsCollection). The problem is that if I remove a book, the reference >>> > to the book is not deleted from ComicsCollection. >>> > >>> > How can I remove properly a book and the reference to the book ? >>> > >>> From the smalltalk image view the problem is usually exactly the opposite: >>> You don’t delete objects but you remove references to them. As voyage maps >>> objects it is a good idea to stay in the object realm. So you should rather >>> remove the book from the collection. This way you won’t get errors just >>> garbage. The „real“ problem that arises then is that the book would still >>> be in the database. Just like it is in the image but there is no garbage >>> collector for mongo. To decide that from the image is not possible. You >>> load only a sub graph from the database into image memory. So you don’t >>> know if there are other objects referencing the book. >>> >>> If your records fit all in memory you could load all collections and books >>> and build the difference between all referenced books in the collections >>> and the total amount of books. The difference will be the set of objects >>> not being referenced by a collection and those can be deleted. >>> >>> If the records do not fit in memory an alternative strategy would be >>> needed. I started to research if it is possible to build a map/reduce based >>> garbage collector for common cases but got distracted. But I have the same >>> problem so I will need to pick it up some time. >>> >>> hope that helps, >>> >>> Norbert >>> >>> >>> >>> >>> >>> If you reply to this email, your message will be added to the discussion >>> below: >>> http://forum.world.st/Voyage-how-to-delete-references-to-objects-tp4755088p4755092.html >>> To start a new topic under Pharo Smalltalk Users, email <a >>> href="x-msg://56/user/SendEmail.jtp?type=node&node=4755097&i=1" >>> target="_top" rel="nofollow" link="external">[hidden email] >>> To unsubscribe from Pharo Smalltalk Users, click here. >>> NAML >>> >>> >>> View this message in context: Re: Voyage: how to delete references to >>> objects. >>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> >> >> If you reply to this email, your message will be added to the discussion >> below: >> http://forum.world.st/Voyage-how-to-delete-references-to-objects-tp4755088p4755102.html >> To start a new topic under Pharo Smalltalk Users, email [hidden email] >> To unsubscribe from Pharo Smalltalk Users, click here. >> NAML >> >> >> View this message in context: Re: Voyage: how to delete references to >> objects. >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >
