Modify dc:created

I know this may sound weird to some people but it would be very handy for me for debugging during development. I would like to artificially “age” a document in steps of 1 year. It would allow me to do test code which responds to the age of a document. I have made a very simple client side thing to modify the dc:created field of the document. The field is changed but it seems the change never gets persisted to the database since it's goes back to its original value after a short while (some cache expires?).

The code I use to modify the creation date is the following:

public void debugAgeDocument1Year() throws ClientException {
    DocumentModel doc;
    GregorianCalendar created;

    coreSession = navigationContext.getOrCreateDocumentManager();
    doc = navigationContext.getCurrentDocument();

    created = (GregorianCalendar) doc.getPropertyValue("dc:created");
    created.add(GregorianCalendar.YEAR, -1);
    doc.setPropertyValue("dc:created", created);

But the change never gets persistent in the underlying PostgreSQL database. Alternate approches and pointers to relevant documentation would be appreciated.

0 votes

2 answers



It doesn't sound wierd at all (at least to me :-). The only way I have found to achieve what you are asking is to override the dublincore logic provided in the Nuxeo base ( found in the nuxeo-platform-dublincore package). Nuxeo recommends not doing this, but personally I see the need for it (as do clients looking to preserve original creation). Testing I think is another good reason.

0 votes

Your answer brings more question. I have looked at DublinCoreStorageService and it doesn't seem to do anything different than what my small function does. That is simply set the dc:create property. I'm wondering what is special about it which makes it not persisted in the database.

This is shameful, but turns out a bug in my configuration made Nuxeo use Derby instead of PostgreSQL and that's why I did not see any commits done on the PostgreSQL. The question still kinda stands because the commit in question still did not get saved in all situations. Since I care little for Derby, I will first switch the config to PostgreSQL and see if the problem can be reproduced.

0 votes