On Dec 21, 2009, at 1:34 PM, Sergiu Dumitriu wrote:

> Hi devs,
>
> Currently the getDocument method always goes to the storage to  
> retrieve
> the document, even if the same document has just been retrieved. This
> means that the following code will not work:
>
> #set($d = $xwiki.getDocument('X'))
> $d.setTitle('the title')
> $xwiki.getDocument('X').getTitle() # will not print 'the title'

+1 in general for the idea. All unsaved changes are linked to the  
Session (known as the Context for us).

For ex in JCR, you even have a Session.save() method that saves all  
unsaved changes in the workspace.
And the methods to retrieve a document are done on the object graph  
itself or from the Session (getItem()), thus ensuring that modified  
objects are returned.

Thus for the new Model, I agree we need to saved the list of modified  
Model objects in our Session (Execution Context). We might also need  
to add a save() method in the Model/ModelContext interface.

Thanks
-Vincent

> I'd like to change getDocument so that it first searches in a map of
> used documents in the current context. This means the following:
> - getDocument searches in XWikiContext.usedDocuments (or better, in  
> the
> ExecutionContext)
> - if found, return the value from there
> - if not, go to the storage, return it to the caller
> - when the document is changed for the first time, i.e. when
> api.Document.getDoc() is called, clone the original document and put  
> it
> in usedDocuments
> - as a special case, PreviewAction also puts the updated context
> document in usedDocuments
>
> This means that consecutive calls for retrieving a (changed) document
> will always return the same object. This prevents possible preview  
> bugs,
> like http://jira.xwiki.org/jira/browse/XABLOG-14 or
> http://jira.xwiki.org/jira/browse/XWIKI-4689
>
> Yet this is an important behavior change. Do you think anybody is  
> using
> this "feature", and actually expects the above code example to work as
> it does now?
>
> Also, we must be careful with the performance, since this new map  
> could
> get big, holding all the documents in the database. Perhaps a LRU
> fixed-size map would be better, although this breaks the uniqueness
> guarantee.
>
> So, WDYT?
>
> 1. Should we introduce this cache?
> 2. Should it be limited in size?
>
> -- 
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to