[xwiki-devs] [VOTE] XWIKI-6990: Reduce the likelihood of having same (hibernate) document id for different documents
Hi devs, I need to fix, and I have a proposed commit at https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e30... 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 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. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Tue, Oct 4, 2011 at 17:25, Denis Gervalle <[email protected]> wrote:
Hi devs,
I need to fix, and I have a proposed commit at https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e30...
Following remarks from Thomas, a better commit is at https://github.com/dgervalle/xwiki-platform/commit/298c87ea8b5957d539d9a6323...
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
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.
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Tue, Oct 4, 2011 at 18:10, Denis Gervalle <[email protected]> wrote:
On Tue, Oct 4, 2011 at 17:25, Denis Gervalle <[email protected]> wrote:
Hi devs,
I need to fix, and I have a proposed commit at https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e30...
Following remarks from Thomas, a better commit is at https://github.com/dgervalle/xwiki-platform/commit/298c87ea8b5957d539d9a6323...
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
Following Thomas comments, I have reviewed this commit again, the new one is at https://github.com/dgervalle/xwiki-platform/commit/a80fe5de8dd21830aa8ae7fbf... 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.
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
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 <[email protected]> wrote:
On Tue, Oct 4, 2011 at 17:25, Denis Gervalle <[email protected]> wrote:
Hi devs,
I need to fix, and I have a proposed commit at https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e30...
Following remarks from Thomas, a better commit is at https://github.com/dgervalle/xwiki-platform/commit/298c87ea8b5957d539d9a6323...
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
Following Thomas comments, I have reviewed this commit again, the new one is at https://github.com/dgervalle/xwiki-platform/commit/a80fe5de8dd21830aa8ae7fbf...
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.
On Wed, Oct 5, 2011 at 11:59 AM, Caleb James DeLisle <[email protected]> wrote:
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.
Not exactly, it used to get it from the context only when it was not provided by the document but it's impossible to have empty wiki in a XWikiDocument since we use DocumentReference to store it.
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 <[email protected]> wrote:
On Tue, Oct 4, 2011 at 17:25, Denis Gervalle <[email protected]> wrote:
Hi devs,
I need to fix, and I have a proposed commit at https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e30...
Following remarks from Thomas, a better commit is at https://github.com/dgervalle/xwiki-platform/commit/298c87ea8b5957d539d9a6323...
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
Following Thomas comments, I have reviewed this commit again, the new one is at https://github.com/dgervalle/xwiki-platform/commit/a80fe5de8dd21830aa8ae7fbf...
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.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On 10/04/2011 11:25 AM, Denis Gervalle wrote:
Hi devs,
I need to fix, and I have a proposed commit at https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e30...
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
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.
+1. -- Sergiu Dumitriu http://purl.org/net/sergiu/
participants (4)
-
Caleb James DeLisle -
Denis Gervalle -
Sergiu Dumitriu -
Thomas Mortagne