[TransWarp] Re: Transaction-Handling in DataModel and default values at creation time ...

[Phillip J. Eby]

At 03:16 PM 5/21/02 +0200, Ulrich Eck wrote:
>Hi Phillip,
>
>--On Freitag, 17. Mai 2002 07:11 -0500 "Phillip J. Eby" 
><pje at telecommunity.com> wrote:
>
>>It's up to the RecordType implementation to do this, if it's appropriate.
>>Typically, upon setting a type, it's necessary to change an existing
>>field, which will of course automatically effect registration.  In LDAP,
>>when you change types you typically change the 'objectclass' field, so
>>that takes care of it.  Just use the record's app-side interface rather
>>than its service-side interface.  That is, use
>>record['objectclass']=[whatever] rather than record.loadDefaults() or
>>record.loadData().
>
>Here we have the chicken and egg problem :)
>
>in Datamodel __setitem___ is defined as followed:
>------------------------------------------------
>def __setitem__(self, key, value):
>
>        oldValue = self.data[key]  <------- raises if record is not 
> initialized for this attribute
>
><snip>
>
>if I setType for a record i need to use loadDefaults/loadData to 
>initialize it correctly,
>but then  i still have the problem that it is not registered in the 
>transaction.
>
>What is better in your opinion:
>1. register a record when calling setType
>2. loadDefaults first and then modify an attribute to be shure it's 
>registered (don't like this one)
>3. ???
>
>another point that i'm not clear about:
>
>when creating a record (setType for the firsttime) should the record be 
>created (in DB)
>in the setTypeFor method (using the Default-Values) or should _saveRecord 
>check,
>if record exists and add or modify it then (i use second approach yet)?

Referencing record.ensureRegistered (note: it's not a method!) will 
register it with the transaction.  record.ensureQueued (also not a method) 
will queue it for future update.  In your case, with LDAP, you probably 
want to do both, and handle additions/type changes in your _saveRecord() 
method.

Note that if you're working with a relational DB, you probably want to go 
ahead and insert a row with default values if possible, and only do 
'ensureRegistered', not 'ensureQueued'.  The reason is that other objects 
modified or created in the transaction may need to reference the row, and 
if you don't do it at the first opportunity, it's possible some other part 
of the transaction might fail due to the row being missing.  (This was 
especially important in ZPatterns, which sometimes wrote things to the DB 
in an "unexpected" ordering.)