[I only just found this message in the wrong folder, for some reason] Ed Leafe wrote: > 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.
This works, thanks! >> 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. Right. > 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. If _newRecords can't be made to work with manual pk's, then it should be ditched. IOW, if we can't rely on isChanged() when isChanged() uses _newRecords. However, perhaps we just need to figure out a different way to define the _newRecords keys. Such as some arbitrary under-the-covers Dabo-generated key, only for the purpose of tracking the new records. I don't really like having different methods of tracking new records for different cases, but that would be a fallback position. Paul _______________________________________________ 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]
