Hey,
Perhaps it would be a viable compromize to drop the "prefix+number"
assumption
for entity IDs in general, but keep it for the kinds of entities we have
right now.
We need to decide if we want to support ids that have another format or
not. This is a boolean thing, as you cannot "sort of support it" and expect
that to lead to good design. The main goal of this threat is getting an
answer to that question.
This would mean that there would be a base class and/or interface called
something like NumericEntityId, which at least ItemID
and PropertyId would
derive from resp. implement. That interface would then be required by
storage
services that rely on the table structure described by Jeroen.
This does not solve the issue. As these interfaces would only accept
NumericEntityId, callers would need to make sure they only provide such
ids. How are they going to do this? I do not see how this could be done
nicely in our codebase. And what happen when we have an entity id type that
does not implement this? We'd need to go tackle all these assumptions to
have it integrate nicely. We'd need to do all the work we need to do now,
plus fixing all new occurrences of these assumptions if we go ahead
pretending we can use them without this further undermining entity id
flexibility. So the approach proposed here is practically the same as
stating "we will not support other formats", except that it lies about this
intend, and causes _more_ work we'd need to do in case we decide the
decision was wrong and we need to support them anyway.
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--