RethinkDB is shutting down

Post by X86BSD » Fri, Oct 07, 2016, 4:37 AM UTC

winter_blue wrote: post #316

tamalsaha001 wrote: post #290

Earlier quoted context omitted.

Now that RethinkDB has no commercial ambitions, will you consider re-licensing to more commercial friendly license?

It's licensed under the Affero GPLv3, but I don't think AGPL license requires you to open source your code, if you're just using ReQL (the API/interface for RethinkDB). GPL/AGPL requires you to share your code if you statically (or dynamically) link (which is a C language family concept) to GPL code, but I don't know if calling an API is considered "linking". I don't think most companies really make any contributions…

Post by Dylan16807 » Fri, Oct 07, 2016, 5:56 AM UTC

jnordwick wrote: post #410

SamReidHughes wrote: post #400

Earlier quoted context omitted.

I think so too. But I don't think, say, not having a 32-bit integer type, and 16-bit and 8-bit integers, is a big problem, if you've got doubles. Maybe it's a nice-to-have. A 64 bit type or bigint would add real value.

I think as far as number types, you NEED (in the you should be considered seriously broken even if you can hobble along without) to have: - a 64-bit float - a 64-bit int everything else can be emulated in code from there and you can play all the encoding games you want to save space when you don't have to use it. This covers 99.999% of the use cases you reasonably see. From there, I would argue, you should also have:…

Post by Dylan16807 » Fri, Oct 07, 2016, 6:32 AM UTC

jnordwick wrote: post #414

Dylan16807 wrote: post #413

Earlier quoted context omitted.

Why do you NEED a 64 bit int? Why not 32 bit? You're not storing pointers in a database. (And then you can implement your 32 bit int in terms of the 53 bits of int-capacity in a double.)

datetimes, aggregations, etc. pretty much anything non-toy in the modern world requires 64 bit int. like I said. read NEED as in you can certainly hobble around without it (pick an appropriate offset and read your 53 bits in relation to it), but like a fracture in a leg, it's still considered broken.

Post by vmware508 » Fri, Oct 07, 2016, 7:36 AM UTC

Post by dkersten » Fri, Oct 07, 2016, 10:17 AM UTC

tshannon wrote: post #301

dkersten wrote: post #235

Earlier quoted context omitted.

I haven't used RethinkDB in ages, but when I did, I used it exclusively for a year. It took a few weeks for ReQL to really sink in, but once it did, I much preferred it to SQL. As my sibling comment says, its very linear: do this then this then this then this. It also feels very much like sequence processing in functional languages (and I was using Clojure at the time, so it really meshed very well). I also found it…

Especially the "known performance" bit. One of the things I fight with constantly in SQL Server is never getting consistent performance from a more complicated SQL query. The query plan could change from one day to the next if the plan falls out of cache. With ReQL you new exactly how indexes were being used, and how the data was being accessed. No trying to guess what the query optimizer was doing in the background.