Re: [xwiki-devs] [VOTE] Adding notions of Locale and Version in EntityReference

On 11/15/2011 12:25 PM, Vincent Massol wrote: Neither of these signatures will work, If you want storage to have any hope of being able to get the same object for the same reference, it must be at least a Map or Pair of <String, Serializable>, if you allow people to pass transient objects such as TCP sockets, they will. More importantly, if you introduce another parameter, there will be no way to search for all documents where param X = value Y. To do it with SQL would require an evil query which did text searching on the parameter field something like: WHERE doc.reference LIKE '%param=value%' To add parameters to a reference and retain the ability to get all documents where "param=value" you would have to modify the database schema unless the information already exists in the XWikiDocument mapping as with language. +1 A constant need for new parameters indicated design problems, including locale information is fixing an error which limited the document reference from the beginning. Building this infrastructure for additional parameters will foster bad practice of using parameters where spaces should be used instead and will allow the creation of arbitrary dimensional data trees where users are only familiar with the standard 1 dimension of filesystems and URLs. +1 I am -1 on version, I don't like it since a document history should be a separate entity which yields documents, as it is now. If we include version in the reference, storage will be forced to remove it on save because we want users asking for a document with no knowledge of the current version to get the current version. This means we already have a magic attribute which is treated differently by storage. In addition, the introduction of a version parameter will allow a user to load a document of a given version with a simple getDocument() call, fooling them into thinking all versions of every document are available in the same namespace, if getDocument(referenceToThirdVersionOfMainWebHome) works then it stands to reason that search("WHERE doc.version=3 AND doc.name='Main.WebHome'") would as well but it won't because that's not how storage works. The introduction of k-d trees for storing documents is not something that anyone has ever used to my knowledge, it may be something that people think they need but like the goto command, something that starts out nice ends up creating more problems than it's worth. This is not correct, the parameters in a URL are never to my knowledge used as a discriminator. Any webserver I can think of uses the parameters as arguments which are passed to the page, not discriminators to select the page. for example: path/to/some/page.php?var=val&varb=42 will load the page "path/to/some/page.php" then execute it, passing var=val and varb=42 as arguments. Caleb