On Wed, Mar 6, 2013 at 11:30 AM, Thomas Mortagne <thomas.mortagne(a)xwiki.com> wrote: s/ObjectProperty/ObjectReference/ -- Thomas Mortagne

On Wed, Mar 6, 2013 at 11:36 AM, Vincent Massol <vincent(a)massol.net> wrote: A litte details about the position I just tough about: we are talking about the index of the object in the list of existing objects here, right ? Not the object "number" we have in the oldcore API. -- Thomas Mortagne

On Mar 6, 2013, at 1:02 PM, Denis Gervalle <dgl(a)softec.lu> wrote: I know, I worked on this… but it doesn't make it right… :) What? That defeats one of the main goal of references which is that you can directly address an entity without having retrieved it first! The reason entities have names is to be able to easily reference them. Using a UUID makes it impossible to reference something without getting it first... If to reference an Object I have to load the Document first, then in practice it means we don't need Object references and they shouldn't be considered entities. For any entity, you should be able to construct a direct reference to it without needing to load anything else. In the 7-8 years of XWiki we've used Class reference and numbers/position to reference xobjects and it has worked quite well IMO. In most cases you have only 1 xobject of a type and it's very nice to be able to say: here's a reference to the first object of type N in document P. Exposing an internal id of a document as reference is a no go for me since it cannot be constructed without retrieving the entity first. Why doesn't it have a meaning? If in my app, my spec says: - each doc has 3 objects of type P and the first one means this, the second one that and the 3rd one that other thing, then the 3rd one has a meaning. It means it's a reference to an entity by a mean other than a name :) We need to decide but we could very well decide that some entities don't have a name and that they can be found/addressed by some other means (as in the case of Object references when locating them through class reference and position). More below ah good, was trying to despair :) If the first one has a meaning, then 2nd or 3rd can also have a meaning, see my example above. Obviously the majority of use cases will be the first one but that doesn't mean the other positions are not needed. 0 = first not null xobject 1 = second not null xobject ... Exactly. Which is why in my proposal we would have to agree that the current notation (thomas calls it syntax) only describes class reference and NOT a name (name = null). If we ever want to also be able to write a string and specify a name in it then we would need to invent a syntax, in the same manner that we currently have no syntax to express a locale in a document reference when expressed as a string. Using a name is very very far in the future so we don't need to invent a syntax for that now IMO. We don't even know if it'll ever happen actually… That seems good for now, even though in some far future we may want to have a class defined in a wiki and an xobject located in another subwiki… or not… ;) It would be slightly misleading to use the serialized class ref as the name IMO but why not... One danger is in code that will use it instead of using the well-known parameters for class ref and position. Maybe, in any case what I meant is that we'll need to make our code use the new way and not use BaseObjectReference as much as possible. equals/hashcode shoudl already work since they already take into account parameters. I think this is a pity and you're closing the door to lots of use cases and you're going to make them really hard and not performant to implement as a consequence. As a user, if I **want** to access the 3rd xobject because it has a meaning for my app, I'm not going to be able to do so. I'm going to need to load the doc and do some queries to iterate over xobject and count to 3… (which obviously is both painful and not performant). BTW your counter-suggestion to drop the position means you're going to break everything that already exists since it's currently possible to reference an object with class and number. It means inventing a new syntax, which is always painful to do. Thanks -Vincent

Hi Vincent, On Wed, Mar 6, 2013 at 4:48 PM, Vincent Massol <vincent(a)massol.net> wrote: So from this and what I read below, I understand you have suddenly decide to revert the new model back to the old way of addressing objects and stop using named objects. This is a major change that should be discussed first and does not have my support right now. True for the old object storage, but was a better a way to avoid what you seems to advocate now ! Ah, you are right, object should have name to be addressable properly. Was only about a temporary compatibility solution for old objects, obviously not a good way to be able to create reference from scratch, but a good way to get stable reference from objects. I disagree, you do not always have to load the document to know an object UUID. You may retrieve the UUID of object by searching the database. This is the only way I have found until now to strongly link object together when multiple objects are stored in the same document. However, most of the time, I avoid this by creating only a single object of a given class per documents when I want to reference them elsewhere. So I may use the document itself for reference. This is precisely why we need name for referencing our objects. I use it since as long as you, and I have mostly worked without any reference to objects since these were missing. I mean I have usually not accessed object unless I have them at hand, since the only correct way to get them was exactly what you explain just above. I do not remember having really retain object number to reference them at any moment except for a few line of code. I have surely never based anything on "this is the third object of that class in that document" since this is not really stable in the current model. I said that I agree with this special case, which is really different IMO than accessing the nth object of document. We had for this special case helper function in XWiki since a long time and these revealed to be helpful. That is not my purpose, it was only my temporary solution waiting for truly named objects, it have been decided to use object numbers (not index !), but this has nothing to do with the current discussion anyway. Maybe this decision influence you however. And when any object get deleted, your meaning vanished. Great design of course ! The mean is bad, the position may change each time object are added or deleted. And I do not think we have real positioning in the current model, which means you cannot really ensure object order at any time. We may, but we need strong reason to introduce that IMO. And other means should be solid, position is not. When you use the first one, and have only one, you may ensure you get the right one whatever the creation/deletion of object happened. This is not true for the other one, and we do not have anything for that. The reason I am -1 for using position, is mainly because position may change overtime for the same object, so this is a really fragile reference, and obviously this is not good design at all for maintaining a reference. Position is perfect during a small piece of code, and bad to be stored as a reference. I see it the other way round. If it is, what is the purpose of renewing the model ? Why do you prefer to step backward instead of going forward to solve our initial issue ? This really afraid me, no more ambition to get it right ? Not repeating useless information does not mean we should not support absolute reference as well. Thinking about it twice, I agrre with you that this is more subtle than it look, since copying a document may be greatly influence by this. We should discuss that further once we agree on the rest. You cannot always prevent bad coding practice, and you may also think about the easy way some may want to use in velocity for example even if this is not optimal. But comparing two references to the same object, one using the name of the object (once we have it of course) and the other the classname will not compare to be equal while these are. We have the exact same situation for locale or version. I am not closing anything, I am just not agreeing to create a solution that will encourage bad design. As a user, if I **want** to access the 3rd xobject because it has a meaning As a user I want to access the right object, I do not want to care about its place, I just need to be able to name it properly. Your use case is simply wrong and induced by the current design. And is need it anyway to access that object, it is you or the API, but it will be done at some point. Have I said you cannot use the BaseObjectReference ? You may do so, but you are stick with the oldcore and the old and bad way of working with object. Again, why not using our energy to find a nice way to reach the named object solution instead of defending a bad design we suffer from since really too long ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

some amendments below. On Mar 7, 2013, at 9:08 AM, Vincent Massol <vincent(a)massol.net> wrote: Correction: remove the wiki part. BTW I'm not saying that you're not justified in your answers. It's actually quite good that you're taking the time to reply and brainstorm about it :) I just don't have much time to work on the new model and I'm frustrated that I couldn't make progress as I would have liked in the little time I had available. Starting next week it's going to be devoxx preparation and others things, and I won't be able to work anymore on the new model for some time… could be long... Looking at xwiki.hbm.xml I see that we have name, className and number so maybe there's a solution to reuse the name property after all and not have to change the schema. Thanks -Vincent

On Thu, Mar 7, 2013 at 9:08 AM, Vincent Massol <vincent(a)massol.net> wrote: Sure, but they will if they need it. They will need it if they want to create reference to an object of a given class and there is more then one of them in the document. Else, they will rely on an iterator and will not create such reference. Once again, without looking the object themselves, talking about the nth objects is a really uncertain bet that you will really get the one you want. No, this is not the same. When you have only one object of that classname, it will be there or not, but when you have several, deleting one of them will change the index of others, and your reference will not refer the same object anymore. This is why using index is poor for creating reference IMO. But you have currently nothing for reordering that list. Explain me how, let say, how you recreate the second object in a list of three once it have been deleted. We have no API for that. Sure, gone but not mixed by the deletion of another document. Sure, but constructing ref using index is hazardous since you could ensure the list is the way you expect it to be. When using names, there is no risk another object cause the one you want to reach to have change its name. You do not need all that. If an object is not the first one (for which I d'like your idea to have a special syntax to reach it by classname), and you have not set a name on it, it means you will be unable to create a reference to it without asking the object itself for its reference. The object should be able to create a unique reference to itself, and this is why I would have preferred the UID solution to the current BaseObjectReference, but that could work too except for the annotation maybe. You will not be referring a particular object that way, only a position in a list of object, this is absolutely not the same. If you want that, call it a ObjectIndex not an ObjectReference. This is where we are not agreeing. Object indexes are not bad by themselves but they are unrelated with references. Using an object index for a reference is bad. Note that the current model does not use an index, but a number. That number is not always equal to the index. It is somewhat more stable, but it does not really help creating reference from scratch anyway. It is like the UUID. No need to have the name as a constraint. This is only a constraint if you want to create a reference from scratch to a given object in a list of object of the same class in a document. Currently we do not create reference to object from scratch, so of course it works well. It means comparing Object references is not that same as comparing Object entities. Sorry about that, I found this sad as well. Anyway, this is too important to be overlooked. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

On Mar 7, 2013, at 9:35 AM, Marius Dumitru Florea <mariusdumitru.florea(a)xwiki.com> wrote: The entity name is a string. It's a black box and you shouldn't have to use a resolver to make anything out of it. That's not the proposal Marius. The proposal is that in the syntax: "wiki:space.page^wiki1.space1.page1[N]", the "wiki1.space1.page1[N]" part is NOT the object name but a class ref + index/number. To specify a name you'd use another syntax (that doesn't exist yet). For example: "wiki:space.page^^freeformname". Thanks -Vincent