5 Oct
2011
5 Oct
'11
11:59 a.m.
3.2 would be rushing and this is a major change which is not fixing a new regression.
I noticed that the cache now gets the wiki name from the document whereas it used to get
it from the context.
Does anyone see any potential problems with this?
+1 for 3.3
Caleb
On 10/05/2011 04:40 AM, Denis Gervalle wrote:
On Tue, Oct 4, 2011 at 18:10, Denis Gervalle
<dgl(a)softec.lu> wrote:
On Tue, Oct 4, 2011 at 17:25, Denis Gervalle <dgl(a)softec.lu> wrote:
Following Thomas comments, I have reviewed this commit again, the new one
is
at
https://github.com/dgervalle/xwiki-platform/commit/a80fe5de8dd21830aa8ae7fb…
and point a) and b) are now:
a) Add XWikiDocument#getLocalKey() which return a local unique text key
like 5:space4:name2:fr
b) Add XWikiDocument#getKey() which return a unique text key like
5:xwiki5:space4:name2:fr
>
>> c) Change XWikiDocument#getId() to use the lowest 64bits of an MD5 hash
>> of XWikiDocument#getKey()
>>
>> d) Deprecate all XWikiCacheStore#getKey(...) and
>> use XWikiDocument#getKey(context) for the XWikiCacheStore map
>>
>> e) Introduce a data migration to convert existing database, also fixing
>> links, rcs, attachements and deleted attachements use of docid.
>>
>> I am +1 only after XWIKI-7006 is fixed (see my previous vote), since any
>> improper access to an outdated database would corrupt it.
>> Currently the patch is ready for 3.3, but if XWIKI-7006 goes in 3.2, I am
>> also +1 to have this in 3.2.
>>
>>
> Hi devs,
I need to fix, and I have a proposed commit at
https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e3…
Following remarks from Thomas, a better commit is at
https://github.com/dgervalle/xwiki-platform/commit/298c87ea8b5957d539d9a632…
Basically, it does the following:
a) Add XWikiDocument#getKey() which return a unique text key like
8:fullname2:fr
b) Add XWikiDocument#getKey(context) which return a unique text key like
5:xwiki8:fullname2:fr