Contact: fumanchu@aminus.org

Log in as guest/dejavu to create tickets

I think I've seen this ORM somewhere before...

Ticket #1 (enhancement)

Opened 6 years ago

Last modified 5 years ago

New concurrent constraint mechanism (triggers, cascade, etc)

Status: assigned

Reported by: fumanchu Assigned to: fumanchu (accepted)
Priority: major Milestone: 2.0
Component: Misc Keywords:
Cc: Estimate (total hours): 16

Some triggers should be immediate, and some should be delayed until the end of a request. For example, changing either the FirstName? or LastName? of a directory record might send a notification, but if both are changed within the same transaction, we wouldn't want two notifications being sent. See the comments for more requirements.

Change History

10/05/05 15:27:44: Modified by fumanchu

Lowest layer may need to be event-based, but a higher layer is needed to declare and enforce guards like:

UnitA.FirstDate? = min([x.Date for x in UnitA.SubUnits()])

If you only work on the per-event model, you might run the above on update, but forget to do so on memorize, for example. A single declaration syntax could handle the "when" for you.

10/05/05 15:28:02: Modified by fumanchu

Don't need action triggers so much as state triggers. There should be a declarative state-change-constraint registry, with triggers on state change.

State change should be concurrent, so that multiple details can be changed at once, and then a single constraint-check/trigger-check performed. Normal code will do this upon each state change (when data dirtied)--some code can call a begintrans/endtrans pair to mark a concurrent block.

10/05/05 15:55:00: Modified by fumanchu

  • estimate set to 16.

12/14/05 18:06:10: Modified by fumanchu

Trigger interference may need to be dealt with on the sandbox level, where each trigger records all of the state it changes. This would allow us to stop recursive triggers, and also to decide trigger firing order in otherwise ambiguous cases.

12/14/05 18:20:14: Modified by fumanchu

  • description changed.

The "high level" of this might be to add a new "properties" module to dejavu at the top level. UnitProperty? would go in there, and so would subclasses which implement on_set: one which immediately calls methods on the current unit or related units; one which sets up a deferred payoff; others? Perhaps UnitProperty?.new could take an argument which results in a subclass being chosen instead of the UnitProperty? base class...

12/27/05 00:04:05: Modified by fumanchu

  • milestone changed from 1.4 to 1.5.

02/16/06 18:10:24: Modified by fumanchu

  • summary changed from New concurrent constraint mechanism to New concurrent constraint mechanism (triggers, cascade, etc).

12/18/06 16:29:11: Modified by fumanchu

  • milestone changed from 1.5 to 1.6.