Which sort of leads me to my next feature, which is bypassing the SQL language. Why use that crusty old syntax when it's equally expressible in JSON, XML or something else. Again I see it just as an API, callable by whatever parser you want, or none at all, if your code generates queries directly.
I'll definitely release some patches when it's done. Maybe I'll call it "ite" - SQLite without the SQL. On Thu, Jun 4, 2015 at 11:23 AM, Nico Williams <nico at cryptonector.com> wrote: > On Wed, Jun 03, 2015 at 06:04:29PM -0700, Darko Volaric wrote: > > Yep, references a another one. Just like the functions, you have to join > on > > the user type information, add it to constraints, etc. > > Once you're extending SQLite3 proper the referential integrity problem > goes away (being no different than the "problem" SQLite3 has of tracking > value types internally). > > > In my case I'm already modifying and maintaining my own version of > SQLite. > > My project is basically a database with a lot of extensions. Submitting > > patches is not an issue. The last time I brought these ideas up I was > > practically chased off by a mob waving pitchforks and torches. Apparently > > almost no-one thinks user defined types is a good idea so there is no > point > > sharing it. I don't expect anyone to help me maintain the code. The > > critical parts of SQLite (like the record read/write) are very stable and > > updates hardly ever affect me. > > I'm not at all sure that UDTs are a bad idea. I do want JSON support, > preferably using jq for expressing transformations (or merely addressing > specific values in a JSON text) of JSON texts. And I'd like bigint (and > bigfloat?) support. Those two types should be enough for easily dealing > with a great many needs for UDTs without necessarily having support for > arbitrary UDTs. A bitstring type would also be convenient for things > like IP addresses and CIDR. > > Given that SQLite3 is in the public domain, you're not obliged to share > your development. But who knows, in spite of all the reasons that using > your "fork" would not be advisable, you might succeed in forming a > community of users. So unless you have reasons not to share your work, > I'd encourage you to share it. If you do share it, you'll want to give > it a distinct name (it wouldn't be SQLite3, would it), and you'll want > to very careful whose patches you accept: if you want to ever be able to > contribute your changes back into the mainline, you'll need to be able > to show that each contribution is permitted by the contributor's > employer and so on. > > I have a long wishlist of features or changes that I don't think the > SQLite3 developers are going to be very interested in at this time. You > might not be either, but if there was a community of external developers > that could pool its resources to make contributions that might be > welcomed by the SQLite3 developers... > > Nico > -- > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
