On 2016/04/15 8:00 PM, Cecil Westerhof wrote: > 2016-04-15 16:43 GMT+02:00 R Smith <rsmith at rsweb.co.za>: > > > ?Do you want me to tell you that you always read all the documentation of > all the software before you use it? I surely do not. And I think most > people do not. To be honest I think you do also not: it is nearly > impossible.
I do want to tell you that, yes. it is not impossible. Maybe not when I am simply the user of some software, but very definitely when I am the programmer and my systems depend on a piece of software from a 3rd party, then I read every bit of documentation, more than once - and I am not special, I am sure that goes for most developers here, but perhaps not all. As for interpreting the documentation wrong, well, that I can do just as well as the next guy! - all the more reason to read it again. > When reading what the documentation says, I interpret it as: we really > would like to comply to the standard. But we cannot. Yes, that is exactly what it says. > I (think I) gave a way to give the maintainers what they want. If there is > a reason that what I suggest will not work, I do not mind to hear it. I'll try explain it more simply below. > > just saying (in this case) you should have read the documentation, I find > not helpful and to be honest a little cheap. Especially because the fix is > mostly for new users. I know what to do now. I just want to make sure that > SQLite gives the least surprise. > https://en.wikipedia.org/wiki/Principle_of_least_astonishment It's not cheap - it's also not how I meant it, but I'll take your point and rest here. > ?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. 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. 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. I am hoping that is as clear as possible with no hint of mocking - I honestly mean it well. >> 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. ? > ?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. If you for instance want to store secret information with per-table user access controls, or run a networked client-server kind of data model, then you should not use SQLite, you should really use one of those. SQLite is much better for local storage though, and even as a software data storage for your own software - as Richard delightfully likes to point out (I'm paraphrasing a bit since I cannot recall the actual quote) - "We'd like you to not think of SQLite as a replacement for Postgress/MySQL/etc.... We'd like you to think of it as a replacement for fOpen()." Cheers, Ryan
