I'm writing a simple code generator in C# for automating common tasks on bussiness applications such as data binding, model and viewmodel generation and record updating.
The generated code uses a data mapper that implements equallity by reference comparision (without id) and flag properties for transient state (if the object was created but not persisted).
For updating the object properties I have 3 options:
On the property setter call an UPDATE for one column only immediatly. This would provide instant persistence without any other mecanism managed by the final programmer, but it would requiere and unnecessary number of UPDATE calls
Mantain a Frozen state on all entities wich would prevent any property set, and BeginModification and EndModification methods, wich would enable property setters and UPDATE all modified columns on the EndModification. This woud requiere the programmer to call this methods wich is undesirable for the code generator, because code simplicity and diminishing programmer intervention is its primary goal
Mantain a timer for each entity (wich can be implemented as a global timer and local counters), and give certain "dirty time" to entities, when a property is setted, its dirty time is resetted to 0 and when its local clock gets to certain values, columns UPDATE would be made. This wouldn't require any extern final programmer code and woud group several property sets on a single UPDATE, because contiguos property sets have almost 0 time between.
The timer aproach can be combined with a CommitChanges method that will call the UPDATE immediatly if desired
My prefered way is the local dirty timer because the posibility of zero programmer intervention besides property sets, the question is: It is posible that this timer aproach would lead to data inconsistency?
If you're writing this as an educational exercise or as a means for further honing your design skills, then great! If you're writing this because you actually need an ORM, I would suggest that looking at one of the many existing ORM's would be a much wiser idea. These products--Entity Framework, NHinbernate, etc.--already have people dedicated to maintaining them, so they provide a much more viable option than trying to roll your own ORM.
That said, I would shy away from any automatic database updates. Most existing ORM's follow a pattern of storing state information at the entity level (typically an entity represents a single row in a table, though entities can relate to other entities, of course), and changes are committed by the developer explicitly calling a function to do so. This is similar to your timer approach, but without the...well...timer. It can be nice to have changes committed automatically if you're writing something like a Winforms application and the user is updating properties through data binding, but that is generally better accomplished by having a utility class (such as a custom binding list implementation) that detects changes and commits them automatically.