Support owned references

[NathanWolf]

Object fields can be of two types:

1.References

2. Internally owned entities

Right now, only #1 is supported- an entity referenced by another entity must itself be a full-fledged unique entity.

This is good for references, but bad for complex object structures, or objects that "own" other objects.

These need to be handled specially. They would not have a unique entity table, instead they would have only the owner/value join table, and the entity field would exist there.

In other words, each instance of the owned entity would only exist within the context of its owner. The PK for this table would be the same as it would be for the sub-table otherwise: (owner.id, child.id). Therefore, a child can not be found directly- it doesn't have a unique id on its own.

Similarly, a list of owned objects is a special exception- the list data table would contain the child class instance data as well.

[NathanWolf]

I'm currently trying to decide on a good name for the markup. Hibernate uses OneToMany for this sort of thing, you have to describe the relationship- that feels to complex and database-speak for most users, to me.

I'm thinking about "reference=false" or "owned=true". I'm open to suggestions.

[NathanWolf]

Decided on "contained" for the markup.

Got into coding, now taking a step back. I'm thinking that there is a more elegant hierarchy for the various fields types I could be taking advantage of.

I think there are two main categories: internal and external. Internal data is stored directly in the entity's table- external data requires a sub-table for storage.

Clearly, the schema creation has to react differently to these two cases- creating additional tables in the latter case, additional columns in the former.

Right now, Lists are the only external field type- everything else is just a single field in the entity table.

But, with "contained", fields will need to be generally extended so that each class field can really point to more than one database column. So, the hierarchy further extends into "single field" and "multi field" classes.

List classes are always multi-field, but it's hard-coded at present: the only two fields are id and value, basically.

However, with contained lists of objects there could be more fields- since the objects themselves are stored in the sub-table, not just a primitive data type or reference.

So, all fields will essentially be able to specify multiple database columns, and will have to be able to get/parse the data to and from those columns, packing them up into objects, in some kind of nice virtualized way.

Otherwise, the SqlStore code is really going to turn into a tangled mess of "if (field instanceof PersistedList) ..." kind of logic.

[NathanWolf]

This is finally done! They're "contained" references now, and I've tested it with lists and with in-class data.

Now I can implement the material/variant system.