81–90 of 186 posts
In the first example, there's a a second thing that surprised me: you delete an entity and it's unique ID gets reused? Is that a good idea? I guess if foreign keys are handled properly then that's not a problem by definition? But it sounds wrong somehow.
>> you delete an entity and it's unique ID gets reused? Is that a good idea? That's default behavior, but it can be altered when creating a table. See; https://sqlite.org/autoinc.html
HN… for the love of god… please please stop trying to make SQLite be something it isn’t. Leave this poor project alone. It’s a great tool if you want to give a local app its own database. If you need concurrent writes and full ACID guarantees of an industrial strength database, use an industrial strength database. Yes, other databases will require you to read more manual pages and configure a service. Higher up front…
I don’t understand why a local app database shouldn’t still have the same basic functionality and data guarantees as the full-sized ones.
Earlier quoted context omitted.
>> you delete an entity and it's unique ID gets reused? Is that a good idea? That's default behavior, but it can be altered when creating a table. See; https://sqlite.org/autoinc.html
Where do you see that they get reused from that link?
In the first example, there's a a second thing that surprised me: you delete an entity and it's unique ID gets reused? Is that a good idea? I guess if foreign keys are handled properly then that's not a problem by definition? But it sounds wrong somehow.
I think that's a security vulnerability. If a parent table ID gets reused, then it's a potential to expose data to a wrong user -- security broked.
I'm not sure if you'd want to set one edition in stone every year. Perhaps every 3 years? Or 5 years? Especially for a long-term project like SQLite, that sounds perfectly acceptable!
Why not a .conf file like everything in /etc or postgresql.conf?