8 Feb
2012
8 Feb
'12
1:08 p.m.
On Wed, Feb 8, 2012 at 12:05, Thomas Mortagne <thomas.mortagne(a)xwiki.com>wrote;wrote:
Hi devs,
Denis just reported an issue he have while he is working on generating
ids for the database: local reference to an object looks like
"space.name^wiki:xspace.class[0]" which is not very local when the
absolute reference is "wiki:space.name^wiki:xspace.class[0]" (will let
him give more details on what issue it causes).
I was simply using ObjectReference to produce the base key for hashing the
object id for the database. This is done using a
LocalUidStringReferenceSerializer, that was initially stripping the wiki as
any local reference serialize would do.
But, since the object name change depending on the wiki were the object is
loaded from, the hash was not really portable between databases. Currently,
to fix this easily and as cleanly as possible, I have hacked my serializer
consider the object reference like it would be using proposal 1/. But this
put some dependence of my serializer on the formatting of the object name
which is bad. An object name no dependent on another serializer would be
more stable, and therefore storable.
I'm not sure what's the best for this.
Here are some ideas:
1/ Relative references for class: change BaseObjectReference to
generate a name based on a class reference relative to the document
reference. So an absolute reference of an object would give
"wiki:space.name^xspace.class[0]" which in turn is not fully absolute
even of you can resolve the class reference based on the document.
2/ Local reference for class: pretty much the same
thing as 1/ but
never contain the wiki. Thing is the current storage does not support
class coming from another wiki so would kind of make it "official" in
the references generated by BaseObject.
3/ Custom serializer in oldcore: overwrite reference serializers in
oldcore and parse the object name to also make the class reference
follow the serializer rules (local, compact, etc.).
4/ Object guid as name: use object guid as name but right now guid
can't be trusted (sometimes not set, sometimes duplicated, etc.) so it
would require to fix some bugs first.
5/ Do nothing: and see this as a limitation of the object reference in
the current storage. That means that anyone that really need a local
reference for a BaseObject should generate the reference the way he
want instead of asking it to BaseeObject before giving it to the
serializer.
Note that all of these solution generate already currently valid
object references, it's mostly about choosing the best default
reference.
WDYT ?
1/ and 2/ mean that code counting on reference always having absolute
reference will be broken, like some event listener on object and
object properties modifications probably (would need to check).
3/ is a bit crappy from architecture point of view but at least the
base object reference stay fully absolute
4/ is a bit dangerous right now and require to fix several bugs
related to guids at least. Also it gives an object reference not very
nice from human reading point of view.
5/ does not fix much even if it's possible to manage with a hack
helper to get local reference but it's a hack
1/, 3/ and 5/ are nothing else that hacks from my point of view so I'm
-0.5 for them
4/ is not a hack but I don't feel very comfortable with object uid
that has never really been used (and so have several blocker bug still
not fixed) so lets say -0 too
2/ is OK if we say that with BaseObject we will never support classes
coming from another wiki. The next storage will have different kind of
names for objects anyway not based on classes from what we discussed.
It's a +0.5 for me (no solution give me 100% satisfaction but this one
is the best until other arguments are exposed)
4/ would have been the best for me if the guid introduced initially to
properly reference object were working properly. The advantage is that we
would never be tempted to hack the object name in anyway. It also solve my
remark about double serialization above, and it render object reference
less dependent.
But considering the issue, and the current implementation it may not be the
best.
-0
1/ and 2/ are the same in fact, since the class is never from another wiki,
I prefer 1/ since it do not have the inconvenience of 2/.
+0.5 for 1/, and +0 for 2/
One way to ensure more stability on 2/ would be to use my
(Local)UidStringReferenceSerializer to serialize the document reference.
The goad of the uid serializers is to stay stable, even if the syntax of
references evolve over time. Using then will avoid double escaping and
unexpected dependencies between references. It could be parse in the
current implementation to get the class reference back, but this works only
for 2/, since we should know in advance if an uid contains a wiki or not to
parse it back.
This would produce: "wiki:space.name^6:xspace5:class[0]"
So, I am +1 for this one.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO