21 Dec
2009
21 Dec
'09
1:42 p.m.
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/