it depends on the amount of objects, but yes... you can play with lazy/eager ways of retrieve subcollections but if you have 10k objects, it will take some time to bring them all :)
Esteban On Feb 8, 2013, at 12:59 PM, Bernat Romagosa <[email protected]> wrote: > OK! It looks like it's working now! Thank you so much! :) > > Bernat. > > p.s. After garbage collection, #selectAll is really slow. I guess this is > normal as all objects have to be retrieved all over from the DB, is this > right? > > > 2013/2/8 Esteban Lorenzano <[email protected]> > no, isVoyageRoot mark the objects of the graph that you want as roots. All > the others are just embedded objects. > Just try adding enableMissingContent to class "D" (I don't know what is the > real name in your case :) > > Esteban > > > > On Feb 8, 2013, at 12:39 PM, Bernat Romagosa <[email protected]> > wrote: > >> Hmm I'm not sure I understand. Now I've tried not even having the objects >> stored in a classvar at all, but saving them from a materialized fuel file >> straight away: >> >> (FLMaterializer materializeFromFileNamed: 'mongodb.obj') do: [ :each | each >> save ]. >> >> It's all ok and working, until I do Smalltalk garbageCollect and there goes >> the "Reference not found" error again, without me having removed any object. >> >> Would making ALL of my classes respond true to #isVoyageRoot fix the issue? >> >> Thanks again! >> >> Bernat. >> >> p.s. se entiende el idioma, no el contenido, pero eso es culpa mía! jeje >> >> >> 2013/2/8 Esteban Lorenzano <[email protected]> >> yes, this is what happens: >> >> You have a graph that can look like this: >> >> A->b->c->D >> >> where A and D represent roots of voyage (#isVoyageRoot = true) >> >> you removed D, but A is not updated (the logic for auto update references is >> too complex, and this is a known limitation of voyage). >> So, in a next cycle you try to bring A to the image, and A is trying to load >> eagerly an instance of D... which does not exists anymore, so you have the >> error. >> To prevent this kind of problems, I use something that I call "eventual >> integrity" :) you can configure your collection to not fail when you try to >> get it and it does not exists. For achieve that, you have to add a setting >> to the class you want to take as "lazy deletable" (is a very dangerous >> property to just allow it by defect). >> You have to do something like this: >> >> D class>>#mongoContainer >> <mongoContainer> >> >> ^VOMongoContainer new >> enableMissingContent; >> yourself >> >> note that who is enabling missing content is D, not A :) >> >> hope it helps. >> >> Cheers, >> Esteban >> >> ps: y si no se entiende nada, mandame un mail privado y lo explico en >> español :) >> >> On Feb 8, 2013, at 12:12 PM, Bernat Romagosa >> <[email protected]> wrote: >> >>> It says "Reference not found", and the method signaling the error is >>> VOMongoMaterializer >> #missingContentFor:id: >>> >>> I can try to set up a minimal test case and sent it to you, would that help? >>> >>> Thanks! >>> >>> >>> 2013/2/8 Esteban Lorenzano <[email protected]> >>> Hi, >>> >>> Voyage should keep a weak cache... objects should be disposed as soon as >>> they are not used anymore. >>> Now... it is saying "Reference not found", or "Lazy reference not found"? >>> >>> Esteban >>> >>> On Feb 8, 2013, at 11:46 AM, Bernat Romagosa >>> <[email protected]> wrote: >>> >>>> Hi! >>>> >>>> We've been trying to migrate the data of our Iliad webapp to Voyage, and >>>> so far everything was going great, until the garbage collector collected >>>> objects it shouldn't have... Here's what we did: >>>> >>>> We used to have all objects stored in an Instances classVar belonging to >>>> their own classes, so: >>>> >>>> I had our classes return true to #isVoyageRoot >>>> ourClasses do: [ :c | (c classVarNamed: #Instances) do: [ :i | i save ]] >>>> I checked MongoDB and all was looking great. From Pharo, we could get all >>>> our instances and explore all of their relationships by OurClass >>>> selectAll. Everything was working, so we thought we didn't need the image >>>> stored instances anymore, thus: >>>> ourClasses do: [ :c | c classVarNamed: #Instances put: nil ] >>>> Smalltalk garbageCollect >>>> RMUser selectAll → (long delay) → BOOM → 'Reference not found RMUser: >>>> OID(3725800612)' >>>> So, should we actually keep references to our instances in the image? I >>>> doubt this is the case, cos that'd mean we still have the 2Gb storage >>>> limitation, and then having an external DB would not be helping much... >>>> >>>> Thanks a lot in advance! >>>> >>>> Bernat. >>>> >>>> p.s. I've also tried saving copies of my objects, but the result's been >>>> the same, after garbage-collecting, I lose references. >>>> >>>> -- >>>> Bernat Romagosa. >>> >>> >>> >>> >>> -- >>> Bernat Romagosa. >> >> >> >> >> -- >> Bernat Romagosa. > > > > > -- > Bernat Romagosa.
