I wouldn't call it 'magical' if the definition is right on the field declaration, and depending on the 'worth' of that particular bit of data (Booleans in this case, and I've got absolutely zero concern to the actual state of said boolean, but taking into consideration the typeless nature of SQLite, NULL/Anything else? --BTW, I'm not dissing on the typeless aspect. Due to my SQL2000 training back years yonder, I always define a type out of habbit, but I'm always aware of the typlessness aspect), and weighing on data loss, versus 'magical data', versus development covering grounds for unexpected results, I'd personally build into the database a safety that would try to protect itself at the database level. Then implementing a constraint based on something like ENUMs, where, I know that a default value can safely be designed on a blank insert (Say a value reporting 'ERROR' of some sort), if something shows up that I'm not allowing in the database, it'd resolve issues of program crashes. Results may be unexpected to the end user, but, there wouldn't be a crash, and you would possibly alleviate the restriction on further processing.
I can understand the concern when looking at a well aged database that you've never seen, do an insert/update and something unexpected shows up without an error. But in situations like that there would be two sources of information to get a direction on why the unexpected result showed up. Right at the table def'n, as well as (more infrequently) database documentation in a KB or in a book/binder or whatever. I can also see where how frequently this WOULDN'T be used, and quite right that it shouldn't be used all the time. However, I've come into an instance where I just care MORE that there is data present and has SOME kind of meaning, be it valid a RELEVANT choice (Not necessarily valid), or something understood by the overhead application, and the program can continue BECAUSE the value entered is expected by the program, regardless if it makes sense to why that outcome is what it is. There are two reasons I've "thought this up". Obviously one is because I said I was doing a new database up and saw a possible connection in the SQLite IDE I use. The other was when playing a game dealing with mods, where if/when one mod breaks, the rest of the game still functions. I'm not kicked out of my game abruptly, and can continue on doing what I need to do, but, that function of that additional mod is either disabled, or eventually comes back due to whatever trigger starts getting it to process what it needs to do. As for the whole magic thing, every freak'n day I get up and I see any of the technology sitting around, I find it magical that it even exists. The fact that this DBE does what it does is magic to me, not to mention the OS variety it can run on, and maintain internal integrity REGARDLESS of what platform it is running on. On Wed, Oct 8, 2014 at 8:38 PM, James K. Lowden <[email protected]> wrote: > > The problem I see with your suggestion is that I can't think of another > situation, with or without NULL, with or without defaults, where > > insert into T (t) value (X) > > results in T.t = Y. You should get what you asked for, or an error, > not a magical transformation. > > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
