31–40 of 88 posts
'SQL’s ORDER BY orders the output data. Similarly, the PartiQL ORDER BY is responsible for turning its input bag into an array.' That is the most important thing for my uses. I deal mostly in time series data, SQL windowing queries are too slow. Turning the set into an array to allow indexing and support easy time series queries is enough for me the use it.
ORDER BY is still in the works: https://github.com/partiql/partiql-lang-kotlin/issues/47
Earlier quoted context omitted.
Also, the PartiQL compiler makes heavy use of closures, each of which becomes a class, so the first time a query executes the JVM has to load a few dozen classes--this probably explains the 86ms more than a lack of JIT optimizations alone.
each of which becomes a class Wasn't part of the whole thing with lambdas that they don't all become individual classes?
Earlier quoted context omitted.
Also, the PartiQL compiler makes heavy use of closures, each of which becomes a class, so the first time a query executes the JVM has to load a few dozen classes--this probably explains the 86ms more than a lack of JIT optimizations alone.
each of which becomes a class Wasn't part of the whole thing with lambdas that they don't all become individual classes?
This is neat. Anyone want to add support for TreeBase/Tree Notation? http://treenotation.org/treeBase/ . It's currently on the backburner to query TreeBases in SQL without having first to convert the TreeBase to sql. Seems like it would be relatively straightforward to use this to do that.
Most of your recent comments link to your project's website. Please stop with the abusive promotion.
A database is so much more than just a schema and validator, but this is being advertised as a database replacement.
And, I want to stress, that this doesn't mean I don't think it isn't useful. I bet there are lots of times where you want to enforce some sort of structure on a bunch of folders with files in them. That's not a database though.
This is neat. Anyone want to add support for TreeBase/Tree Notation? http://treenotation.org/treeBase/ . It's currently on the backburner to query TreeBases in SQL without having first to convert the TreeBase to sql. Seems like it would be relatively straightforward to use this to do that.
Most of your recent comments link to your project's website. Please stop with the abusive promotion.
This is pretty nice. If only because using a SQL dotted syntax seamlessly with JSON data.
Earlier quoted context omitted.
each of which becomes a class Wasn't part of the whole thing with lambdas that they don't all become individual classes?
They're not classes in source code . As an implementation detail, certain compilation strategies do generate them anyway.
Earlier quoted context omitted.
Most of your recent comments link to your project's website. Please stop with the abusive promotion.
I don't find it abusive, the comments seem relevant and it's a open source library.
Interesting that they opted for a relational rather than a categorical one; the latter is proving to be more flexible [0]. [0] https://www.categoricaldata.net/
Earlier quoted context omitted.
Most of your recent comments link to your project's website. Please stop with the abusive promotion.
I have real problems with TreeNotation advertising itself as "a software-less database system". It's basically abusing your filesystem to store a tree data structure and using git to handle concurrent updates. That's great, except for the part where they ask "does it scale"; and the answer is yes, but should be no. A database is so much more than just a schema and validator, but this is being advertised as a database…
I have not used TreeBase for anything other than collaborative knowledge bases. Haven't even thought much beyond that. Thanks for letting me know that wasn't clear.