search

mozilla / mentat

UNMAINTAINED A persistent, relational store inspired by Datomic and DataScript.
https://mozilla.github.io/mentat/
Apache License 2.0
1.65k stars 115 forks source link

Implement simple pull expressions #638

Closed rnewman closed 6 years ago

rnewman commented 6 years ago

This reworks the projector, adds parsing and projection support for pull, and implements the actual pull mechanism itself on top of the attribute cache. Finally, it adds a rough implementation of display for the CLI.

This supports simple pull: either (pull ?some-var [:x/y :z/a]) or (pull ?some-var [*]). We don't yet support depth, aliasing, limits, or recursion.

rnewman commented 6 years ago

Summary from Slack conversation:

Aye. OK, I think I’m convinced.

I don’t see how to lift multivalued attributes to meaningful things that don’t look like nested lists.

And if you have list outputs, the churn is there to build map outputs. OK.

ncalexan commented 6 years ago

Just a note:

mentat=> .q [:find (pull ?e [:db/ident :db/doc 10]) :where [?e _ _]]
Error(MentatError(TranslatorError(ProjectorError(NotYetImplemented("complex aggregates")))), State { next_error: None, backtrace: None }).

is misleading. I think what's happening is that the parser isn't yet "committing" to the pull expression, so the 10 throws it off into the aggregate parser, and that's not what's wanted.

I tried to make the tx parser commit to a branch earlier and found it pretty frustrating. I met to ask Marwes about it but haven't gotten around to it.

ncalexan commented 6 years ago

Another note: I think we should grow some sort of representation of the pull structure for explaining the query plan. Right now we see:

mentat=> .eq [:find (pull ?e [:test/multi]) :where [?e :test/multi _]]
SQL: SELECT DISTINCT `datoms00`.e AS `?e` FROM `datoms` AS `datoms00` WHERE `datoms00`.a = 65536
Plan: select id | order | from | detail
  0|0|0|SEARCH TABLE datoms AS datoms00 USING COVERING INDEX idx_datoms_aevt (a=?)

which could use a suffix about pull processing.

rnewman commented 6 years ago

I think what's happening is that the parser isn't yet "committing" to the pull expression, so the 10 throws it off into the aggregate parser…

Yes, exactly. We try the pull parser, and it fails, so we move on.

Our parser needs to be reworked to check for the first element instead of trying the whole branch, or it needs to use expected markers.

rnewman commented 6 years ago

I think we should grow some sort of representation of the pull structure for explaining the query plan.

676.