>I am going to post here a response I got from Tim Penner in the TAOW a bit earlier today. While it does not change my mind that this issue should be characterized as a bug, it does clarify what the issue really is.
It's a bug. If 4D wants to document it as standard behavior, that's their business. But it's still a bug and will lead to real-world problems. This is the kind of bug I'd rank *extremely* serious. Why? Well, imagine any number of data change scenarios some of which change the field on one way and some in another. Depending on the exact sequence of steps the same modification will result in putting the data into a different state. This is exactly the sort of situation that can run undetected for days/weeks/months in the field. And then what do you do? There is literally no way to unscramble the eggs. You have *no idea* what quality your data is at that point. It has any number of undetectable, subtle flaws. The number may be zero, the number may be .0005% of the candidate fields, it may be 7.23% of the candidate fields. Unless you've got source data to completely rebuild everything from scratch, you'll never know and never be able to fix it. Object fields sound better and better to me all the time ;-) They're non-relational, accessed through a "novel" and incomplete JSON serialization scheme, take a lot of space (the same data in primitives takes less room), have a bunch of adjacent/extra commands devoted to working with them....and, I'm told, are *not* designed to be used for the majority of cases where JSON fields are commonly used in ORDBS and NoSQL systems. I just don't get it. Anyway, modifying and saving a field of this sort should be *deterministic*. Making it functionally non-deterministic isn't defensible for a RDMS in any way. Input --> [Function] ---> It depends That's fine if you want something random, it's not fine in any other case. It's a bug. But, again, 4D is free to say it isn't. Their business, their rules. > Am I the only one that was clueless that there is a field dirty field flag that controls whether or not a field gets updated or not during a save record. Guess that does make sense. For a long time you would bump up against this on large data types and the Old() function. That's about the only practical way I remember it being an issue for us. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
