On Wed, Feb 8, 2012 at 13:57, Thomas Mortagne <[email protected]>wrote:
> On Wed, Feb 8, 2012 at 1:08 PM, Denis Gervalle <[email protected]> wrote: > > On Wed, Feb 8, 2012 at 12:05, Thomas Mortagne <[email protected] > >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/ > > Actually there is a big difference between 1/ and 2/: in 2/ the class > part of object name for the same class whatever the document is always > the same (the local name of the class) so it's more stable while in 1/ > it could change depending on the document space. It's also more clear > from the start what is the name of an object if you know the class > (useful for object related events to match on the reference). > Ok, I do not get this. So I am -0 for 1/ than. > > > > > 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 > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > >> > > > > > > > > -- > > Denis Gervalle > > SOFTEC sa - CEO > > eGuilde sarl - CTO > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
