41–49 of 49 posts
Does cube support dynamically figuring out joins or is each cube a hard coded set of joins? My similar, much less polished project doesn't require you to specify joins ahead of time outside of optionally defining a tree-like table lineage: https://github.com/totalhack/zillion
Does cube support dynamically figuring out joins or is each cube a hard coded set of joins? My similar, much less polished project doesn't require you to specify joins ahead of time outside of optionally defining a tree-like table lineage: https://github.com/totalhack/zillion
What's happening with this license? I am always worried when the GH license detector says ":shrug:" and I don't know of any easy way to diff the license file against what I presume is a GPLv3 base layer(?) https://github.com/totalhack/zillion/blob/v0.9.14/LICENSE
My only gripe was the cube definition. It uses a weird JS-like DSL, but not real JS. You can’t use any packages or anything. Feels like a strange limitation. Also lacks types, which are table stakes these days.
We’ll probably adapt it in the coming SaaS build out!
I’ve toyed around with Cube and it’s certainly a solid and mature product! My only gripe was the cube definition. It uses a weird JS-like DSL, but not real JS. You can’t use any packages or anything. Feels like a strange limitation. Also lacks types, which are table stakes these days. We’ll probably adapt it in the coming SaaS build out!
Earlier quoted context omitted.
What's happening with this license? I am always worried when the GH license detector says ":shrug:" and I don't know of any easy way to diff the license file against what I presume is a GPLv3 base layer(?) https://github.com/totalhack/zillion/blob/v0.9.14/LICENSE
I just did a diff of it against https://www.gnu.org/licenses/lgpl-3.0.txt > and the only differences are the lines above "GNU LESSER GENERAL PUBLIC LICENSE" at the top and a blank line at the bottom.
It looks very important, popular and well established, but what is it? I looked at the README hoping to understand what a semantic layer for building data applications means but no love. It helps data engineers and application developers access data from modern data stores, organize it into consistent definitions, and deliver it to every application. Like an ORM? Or a middleware? > Cube was designed to work with all…
As part of the Cube team, I have to admit that all descriptions in the sibling comments make a lot of sense. Of course, the "semantic layer" thing is quite known to data engineers/analysts and other data folks in general (they also know things like "metrics store", "headless BI", etc.) but not that well known outside of the data space. Probably, it would be best to describe what are the major use cases Cube is create…
This is a frontend for data is that right? That's a phenomenal concept if performance is a major priority. Does it work with Salesforce?
Re: Salesforce. The best way to integrate two is to move (ETL) the data from Salesforce to a data warehouse and have Cube connect to that data warehouse. Works really well in the real world!