NathanWolf
commented
13 years ago I think there are a few places in the reference system where it doesn't quite follow references far enough to handle this- for instance: when binding to a reference, the parent class just looks at the references' id type, and creates a field of that type.
In an example where you have a class with another class as its id: let's say: class ChildClass { @Persist(id=true) public IdClass myIdReference };
And then you have a parent class that referenced this child: class ParentClass { ... @Persist ChildClass myChild; }
The binding from parent to child would get confused when trying to set up the proper data type for storing the relationship.
It would need to pass through the correct virtualized interfaces all the way down to do this, so that ChildClass can potentially return the type of IdClass's id, and so on as far down as it needs to go to get to a primitive id type and value.
I don't think it'll be a big change, it's just something I haven't exercised yet, and it occurs to me that it probably wouldn't work right.
First, decide whether or not this is a good idea.
I think would it be handy, perhaps necessary- if you want to essentially extend an existing data structure, such as storing some data per player. You could just make a new data structure with String id of playerId, but it would be more referentially consistent to have an id of Player (or User, whatever I have to make the player DAO named....)
In the end, the data is the same- a text id of playerId, so it's really just semantics. I think I'd like to support it, though.