[xwiki-devs] Local object references are not that local
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'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) -- Thomas Mortagne
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/ 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
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).
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
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
participants (2)
-
Denis Gervalle -
Thomas Mortagne