Quoting Rickard Öberg <[email protected]>:
The main reasons we used the simple property name instead of the
qualified property name is that it makes refactoring of data within
an entity much easier. You can split mixins, combine mixins, rename
mixins, and all sorts of things, without having to do any database
refactoring. In the past I have found this convenience to be quite
useful, especially in the early phase when where properties are
defined tend to change a lot. Another reason is that since using
qualified names would ONLY be useful if there is a clash, it's a lot
of overhead to store the qualified names "just in case".
But the issue remains that if you are not careful, you can end up
with an entity that have many properties with the same name, and
which will give you trouble without warning. My suggestion to this
is that we simply add a warning, maybe even consider the assembly
faulty, if an entity has several properties (or associations) with
the same name. That would ensure that it's impossible to get an
application that has these issues.
WDYT? Any other ideas?
I think in the earlier phase when properties are changing a lot, you
also are developing on quite fast pace, and not having much of a
really persistent data, and that it's ok to wipe persistent data for
each development cycle. I don't see much more (performance) overhead
in saying qName.name() than qName.toString() when storing entity to
database.
Also, I would imagine my apps at some point containing different
interfaces with similarly named properties. Even by having some simple
but extensible composites might result in that. In either way, I think
it is wrong to completely take away possibility of having two
different types with same-named properties. Maybe give user a choice
in this matter? Like, some kind of general ES configuration, which
would have some "useQNamesAsKeys()" property. If it is set as true,
then it would use QNames as keys. If it is false, or missing, then use
current scenario.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
