Am 27.11.2013 um 14:28 schrieb Sabine Knöfel <sabine.knoe...@gmail.com>:
> Hi Norbert, > > ooh sorry, it was absolutely NOT my intention to critisize your explanation > I wanted to say it is complicated for my small brain ;-) I am very happy > about your quick answer which helped me finding a solution for my problem!!! > sorry! > No pun taken. In fact _I_ was criticizing my explanation because it sucks :) So now let’s stop it because we are germans not canadians. No more sorrys needed. > This was the post FROM Johan about the documentation: > http://forum.world.st/Cleaning-up-Voyage-Documentation-td4723834.html > > LOL now, after writing the answer I understand the joke ;-) (of Johan, from > johan) > Ah, the other Johan! It is good to know because I did some changes to MongoTalk so I see what I can add. Norbert > Sabine > > > > > > On Wed, Nov 27, 2013 at 2:17 PM, Norbert Hartl [via Smalltalk] <[hidden > email]> wrote: > > Am 27.11.2013 um 14:05 schrieb Sabine Knöfel <[hidden email]>: > >> Hi Norbert, >> >> thank you very much for the clarification. >> >> I had to read it several times but now I understand and I know what to >> change in my model for this (something with references to objects which have >> been deleted by the user). >> > Yep, it _is_ a horrible explanation but the only one I can come up in a short > timeframe :) Making it easily readably and clear would talk some more time. > >> Perhaps your answer is also interesting for the documentation of Johan. >> > Uh? I’ve never seen a documentation about Johan. That is a nice idea! I was > always thinking about how to use him! > > Norbert > >> Greets >> Sabine >> >> >> On Wed, Nov 27, 2013 at 1:44 PM, Norbert Hartl [via Smalltalk] <<a >> href="x-msg://256/user/SendEmail.jtp?type=node&node=4725585&i=0" >> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >> >> Am 27.11.2013 um 13:20 schrieb Sabine Knöfel <[hidden email]>: >> >> > Hi Esteban, all, >> > >> > I work with mongo daily an it works fine, I am very happy with it. >> > >> > As you told me, with >> >>> VORepository current reset. >> > I can force re loading all objects from database and resetting the cache >> > completely. >> > This is helpful for development eg. after changing the magritte >> > descriptions. >> > >> Indeed. You need to flush/reset the repository in order to have new >> descriptions to take effect. >> >> > My question: >> > Is there a possibility to make a query and tell voyage that THIS query >> > should be done within the database and NOT within the cached objets? And >> > that all objects and the child objects from this query are loaded freshly >> > from database into the cache. >> > >> All queries go to the database. The cache is just used at resolve time. And >> it is necessary to have identical objects. Meaning you query the database >> directly and then objects are materialized. If the object is already in the >> cache the cached one is returned. Otherwise you would lose identity because >> having two requests containing the same object as a result would lead to two >> objects instead of one. You could only load trees instead of a graph. >> >> > My concrete situation: >> > I want that if the user logs in, his objects are loaded from database and >> > NOT from cache. This means the person, his trips etc. >> > >> > And the question coming along with this: >> > How long does the cache keeps objects/when are they reseted (except the >> >>> VORepository current reset)? >> > If I would never take a new image and never make a reset, would all >> > objects >> > remain in the image (and the database objects wold never be read)? In this >> > case what about the size of the image? >> > >> I’m not sure on this one. I think the cache does not clean anything. The >> thing about being able to load a graph I wrote above has also the constraint >> that all loaded objects that are still participating in the active graph >> need to be in the cache. But then the cache is a weak dictionary meaning >> that all objects leaving the active graph are removed from the cache (well >> at GC time, I think) >> Norbert >> >> > Regards >> > Sabine >> > >> > >> > >> > -- >> > View this message in context: >> > http://forum.world.st/Mongo-cache-vs-database-objects-tp4725554.html >> > 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/Mongo-cache-vs-database-objects-tp4725554p4725577.html >> To start a new topic under Pharo Smalltalk Users, email <a >> href="x-msg://256/user/SendEmail.jtp?type=node&node=4725585&i=1" >> target="_top" rel="nofollow" link="external">[hidden email] >> To unsubscribe from Mongo cache vs database objects, click here. >> NAML >> >> >> View this message in context: Re: Mongo cache vs database 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/Mongo-cache-vs-database-objects-tp4725554p4725590.html > To start a new topic under Pharo Smalltalk Users, email [hidden email] > To unsubscribe from Mongo cache vs database objects, click here. > NAML > > > View this message in context: Re: Mongo cache vs database objects > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
