[xwiki-devs] [VOTE] XWIKI-6990: Reduce the likelihood of having same (hibernate) document id for different documents
4 Oct
2011
4 Oct
'11
5:25 p.m.
Hi devs,
I need to fix, and I have a proposed commit at
https://github.com/dgervalle/xwiki-platform/commit/068c24793dd77daa826765e3…
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
4 Oct
4 Oct
6:10 p.m.
On Tue, Oct 4, 2011 at 17:25, Denis Gervalle <dgl(a)softec.lu> wrote:
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
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
5 Oct
5 Oct
10:40 a.m.
On Tue, Oct 4, 2011 at 18:10, Denis Gervalle <dgl(a)softec.lu> wrote:
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
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
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.
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
12:29 p.m.
On Wed, Oct 5, 2011 at 11:59 AM, Caleb James DeLisle
<calebdelisle(a)lavabit.com> 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:
--
Thomas Mortagne
On Tue, Oct 4, 2011 at 18:10, Denis Gervalle
<dgl(a)softec.lu> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
12 Oct
12 Oct
11:06 a.m.
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/068c24793dd77daa826765e3…
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/
4723
days inactive
4731
days old
5 comments
4 participants
participants (4)
-
Caleb James DeLisle -
Denis Gervalle -
Sergiu Dumitriu -
Thomas Mortagne