Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differences with others query packages #1

Closed
scls19fr opened this issue Jun 5, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@scls19fr
Copy link

commented Jun 5, 2018

Hello,

Seeing JuliaDatabases/DBAPI.jl#17 (comment)
I wonder what are differences between DataKnots.jl from @rbt-lang (@xitology ...) which is based on query combinators described in https://github.com/rbt-lang/rbt-paper/blob/master/pdf/rbt-paper-2016-12-14.pdf

and others packages such as:

What features are possible with DataKnots.jl that aren't possible with others libraries.

Kind regards

@xitology

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2018

This is not a comprehensive list, but here are some of the features:

  • Unlike DataFrames, DataKnots' data model supports nested and circular structures, which makes it a suitable model for working with XML, JSON and SQL databases.
  • DataKnots separates grouping and aggregate operations, making split-apply-combine pattern unnecessary.
  • DataKnots aims to be a comprehensive alternative to SQL. In particular, it should support closure operation like SQL's CONNECT BY, OLAP cube operators as well as window functions.
  • Unlike LINQ, its query model is a combinator algebra similar to XPath and does not rely on bound variables or anonymous functions. This enables simple declarative syntax and also makes it easier to assemble queries dynamically.
@davidanthoff

This comment has been minimized.

Copy link

commented Jun 5, 2018

Unlike LINQ, its query model is a combinator algebra similar to XPath and does not rely on bound variables or anonymous functions. This enables simple declarative syntax and also makes it easier to assemble queries dynamically.

Could you expand a bit on that? LINQ doesn't really rely on anonymous functions, the whole IQueryable side of things is based on expression trees, right? Or did you refer to something else there?

@xitology

This comment has been minimized.

Copy link
Contributor

commented Jun 5, 2018

Yes, I mean the surface syntax of LINQ where lambda abstraction is used to introduce bound variables. For example, a LINQ query

employee.Where(e => e.salary > 100000)

is written in DataKnots without any binding syntax as follows:

@query employee.filter(salary > 100000)

or, in a fully desugared form:

field(:employee) >> filter(field(:salary) .> 100000)

There is a corresponding difference in semantics. The LINQ code transforms a dataset; DataKnots builds a new query object from primitive queries such as field(:salary) using query combinators .>, filter and >>.

@davidagold

This comment has been minimized.

Copy link

commented Jun 7, 2018

  • Unlike StructuredQueries, DataKnots appears to be under active development =p

Seriously though, the API I was working on was particularly focused on manipulating tabular data. (That may change if I ever start seriously developing the package again.) I think it may be similar to the present package insofar as the invocation of a manipulation command creates an intermediary graph object that represents the "atomic" elements of the manipulation, but I won't pretend to understand the internals of the present package.

@xitology xitology closed this Jun 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.