On Oct 11, 2008, at 11:32 PM, Paul McNett wrote:
> The following patch appears to fix my issue, but I'm not entirely
> sure why:
I have a feeling that your calling of save() within new() is a
condition that I hadn't tested for. I know none of my apps do anything
like that. You're probably exposing a flaw that simply was not
anticipated. IIC, I can't see how that could hurt anything, and would
make doubly-sure that any markings of that record as 'new' would be
erased. I've committed a variation of the change that will handle
cases where that key is not present.
> Another question I have is if it is possible to maintain *either*
> the _newRecords dict *or* the new record flag, but not both, as it
> seems to be a redundancy. I put the _newRecords dict there for
> performance reasons (to avoid having to iterate _records to find out
> if new records exist) but if it is better to maintain the flag
> instead we should remove _newRecords.
I was thinking about this, too. The performance gain is significant,
but at the cost of supporting manually-set PKs. The absence of the
flag is a definite sign that it is not a new record, but the absence
of a records PK value in _newRecords is not.
I can think of several approaches. One would be to monitor the PK
field, and catch any changes to it if the record is has the new record
flag, and update _newRecords accordingly. That would allow us to
retain the performance advantages for most 'ischanged' calcs, but at a
small price when modifying values. The other would be to handle the
situation of no auto-populate and no default value for a PK, and use
the flag system in that case, and the _newRecords everywhere else.
-- Ed Leafe
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/[EMAIL PROTECTED]
