2016-04-15 22:04 GMT+02:00 R Smith <rsmith at rsweb.co.za>: ?I do not think it is. When you add something to the database to signify >> that a primary key is not allowed to be NULL, then this is not in an old >> database, ergo in the old database NULLs are allowed. Where does backward >> compatibility get broken? As I see it, it is as with partial indexes. > > > > ? >> >>> B. Your suggestion would break backward compatibility, no matter how >>> "light" you coat it. >>> >>> ?I really do not see this. Could you expand on that? >>> >> > Imagine a program written 2 years ago, for instance works on all Apple > computers, or perhaps Android phones. In fact, imagine several programs > where the programmers used, either through conscious decision to employ a > "feature" of SQLite, or perhaps simply out of ignorance, the NULL values > allowed in PK situation. > Some time later, SQLite gets updated with your requested new default. > These programs get re-compiled with defaults, or even just use the packaged > SQLite that are now updated inside OSX or Android, etc. Suddenly, their > programs do no longer work, Keys fail to get inserted... Users have devices > crashing everywhere. Apple perhaps quickly rolls back to a previous version > that was not so damaged, but every compiled-in version of the SQLite code > is out in the wild causing problems. SQLite runs on billions of devices and > systems. >
?It is clear as daylight now. Thank you for the explanation. I hope that I was not to pesky.? > This is what backwards-compatible means, that a system and data will still > work as it always worked, even after you upgrade the engine. To get to your > example of Partial indices - if a DB did not use them before, then it still > doesn't use them, all is well. Only new DB's could use them. > ?Yeah, I did not think it through enough. Luckily the maintainers think better about consequences as I did.? > So if you opt for a pragma that lets you avoid NULLs once you activate > it... sure, but who will that really help? People will need to read the > documentation to even know that pragma exists (which you pointed out they > don't usually do in the first place), and simply /knowing/ the reason for > that pragma, will obviate the need for it. > ?It does not add much then no. The only thing is that people could keep database definitions ?the same? for different databases.? ?The only change I would like is in the documentation. It should be ?impossible? to start using SQLite without knowing this pitfall. Not for me, I know it now, but for future users. ? > I am hoping that is as clear as possible with no hint of mocking - I > honestly mean it well. ?Yes, I now understand it. Next time I should curb my enthusiasm. ;-) C. The suggested work-around would introduce more complication than it is >>> solving. >>> >>> ?I do not see that either. Could you enlighten me? >> > > I trust this point was made above too. > ?Certainly.? ? > ?I like SQLite very much also. I even gave a presentation about it on >> T-DOSE. As you can see from the plethora of questions I ask(ed) I want to >> get serious with it. I do not use MySQL anymore and plan to migrate what I >> still have in H2 to SQLite also. :-) I do not say there is never a reason >> for another database, but I think that in my case there is not (at this >> moment of time). >> > > That's great news :) > Let me just note that we do not really shun the likes of Postgress, MSSQL, > MySQL etc. - those systems answer a different need. ?Me neither, but when SQLite is enough why add the complications of the other type of database? At my work they use DB2: I do not think SQLite would be a good replacement there. :-D ? ?I use it for logging. It is much easier to find something, or delete the parts you do not need anymore. Thanks for the patience. -- Cecil Westerhof
