Okay, the Xmldoom definition format needs to change drastically. There are a couple of new rules that need to go into effect regarding the object structure inorder to allow for more complex operations.
- No "master" objects. Previously, every database would have a "master" object that wasn't attached to an object table which would be able to add parentless objects. These will be replaced with the ability to make "object" objects without any table. You can have an abitrary number of these. "Why would you ever need multiple "master" objects?", you ask. Well, eventually you'll be able to add and extend the "object types" in both the PyRE and the generated code. You can break-up Xmldoom functions into logical objects and then add non-Xmldoom functionality to them that address the same logical seperation.
- An object key will refer to a whole table and all its primary keys. This means we will have object with more than one key value.
- Transaction objects. This is a totally new idea for Xmldoom. Its an object that inherits properties (plus gets and adds) from a table object and additional properties (not sure about gets and adds) defined on a connecting table. For example, consider the tables: items, orders and items_ordered. "items" and "orders" are obvious, but "items_ordered" is a connecting table that attaches items to a particular order along with a quantity and sale price. We want an Order object with an AddMethod like: "Order.AddItem(item_id, quantity, price)" and a GetMethod that returns an Item object augmented with the properties "Quantity" and "Price".
- Table-less objects can't add any object that has a foriegn key reference or parent.
- Table objects can't add any object that doesn't have foriegn key reference to (or parent of) its primary key.
Overall the current xml format has outlived the original design goals. It was never meant to do all the shit I am trying to make it do. But I just don't have the energy or the insight to rewrite it now. What I really want is an "object only" version. It is getting really annoying dealing with table definitions. I have gotten alot of good xml design ideas from Relax-NG which absolutely soars in abstraction. But a ground up change is something I would like avoid right now. Once I start working on the compiled xml format (which knows nothing about tables at all), I'll start porting the object specfic features back into the definition. Hopefully, that will give me a real understanding of the abstraction required for an "object only" format.