>> 1. Insert/Delete order of dependent objects,
>> 2. Insert/Delete order including reflexive relationships.
>> 3. Delete/Update order for delete rules ("cascade", "nullify",
>> "deny"). BTW, does "deny" throw an exception when triggered?
>> 4. Handling inserts/deletes of the records in the join tables for
> flattened
>> relationships.
>
> These are in the latest CVS version, aren't they? I am going to have a
> look and see how it can be fitted into my commit. The question is are we
> going to stick up to ContextCommit or you plan to remodel the whole
> thing?
Let me send my later notes on redesign that I sent to Andriy privately a
few hours ago. Andriy was making a good point, that while normal
Insert/Delete/Update queries are generic, we can do better
performance-wise for internal commits from DataContext. I was trying to
solve the problem of generic vs. optimized. This is to bring our general
discussion to more detailed design terms:
=======================================================================
I still don't want to break the overall arcitecture, jumping the layers.
So do you think we can create a special "ObjectModifyQuery extends
AbstractQuery" and an optimized translator for it? I am thinking about
the scenario like this:
- DataContext will send (unordered) ObjectModifyQueries (can be
insert/update/delete, can also be a batch) to DataDomain.
- DataDomain will sort them by node.
- Each DataNode will work with its own subset, sorting them any way
appropriate, and using a special translator to avoid our complex
expression translation code.
Do you think this is still not optimized enough this way?
Andrus
This archive was generated by hypermail 2.0.0 : Mon Jan 27 2003 - 12:23:00 EST