Skip to content
This repository has been archived by the owner on Sep 12, 2018. It is now read-only.

Db and errors #341

Merged
merged 13 commits into from
Feb 24, 2017
Merged

Db and errors #341

merged 13 commits into from
Feb 24, 2017

Conversation

ncalexan
Copy link
Member

This commit sequence is a bit all over the place. It's all preparatory work for a top-level Conn, as tracked by #296. That's still in progress in my tree.

The first series of commits, up to and including ncalexan@201ffc7, are about separating the SQLite bits from the DB type. See the comments around the MentatStoring trait.

The last few commits, including and following ncalexan@b8a7c84, are about moving the existing code to error-chain. You can see the chaining (a little), and unifying some error types. This also surfaces errors out of combine; see some of the commit messages for notes.

@ncalexan
Copy link
Member Author

@rnewman lots of code movement in the DB layer, and then some real work to use error-chain throughout. Hope it makes some sense.

.chain(once(&tx as &ToSql)
.chain(once(to_bool_ref(added) as &ToSql)
.chain(once(flags as &ToSql)))))))
.chain(once(to_bool_ref(added) as &ToSql)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really need some macrology here! Alas, it's beyond my current skills.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I concur: #261.

db/src/debug.rs Outdated
e: to_entid(schema, e),
a: to_entid(schema, a),
e: to_entid(schema.borrow(), e),
a: to_entid(schema.borrow(), a),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make a difference if we borrow() only once?

db/src/debug.rs Outdated
e: to_entid(db, e),
a: to_entid(db, a),
e: to_entid(schema.borrow(), e),
a: to_entid(schema.borrow(), a),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it make a difference if we only borrow once here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, so I've lifted a temporary.

///
/// Use this to create temporary tables, prepare indices, set pragmas, etc, before the initial
/// `insert_non_fts_searches` invocation.
fn begin_transaction(&self) -> Result<()>;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a difficult thing to abstract, but yeah, I guess!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I'm basically just punting and working in a live scratchpad until the abstractions get more clear.

fn from(e: combine::primitives::ParseError<&'a [edn::Value]>) -> ValueParseError {
ValueParseError {
position: e.position,
errors: e.errors.into_iter().map(|e| e.map_range(|r| {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I confess that I'm a little surprised to have errors be something we can move, but I guess that helps!

I was worried that we'd have copying on the error path, where the error might be due to OOM…

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can only imagine this does badly in OOM situations, but we're not going to get combine::ParseError instances in those situations anyway. I guess it's possible we get ParseError into OOM... but that should blow up during this mapping.

}

#[allow(dead_code)]
pub fn clause_seq_to_patterns(clauses: &[edn::Value]) -> WhereParseResult {
Where::clauses()
.parse(clauses)
.map(|x| x.0)
.map_err(|_| WhereParseError::Err)
.map_err::<ValueParseError, _>(|e| e.translate_position(clauses).into())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fixes #328.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will close it when I push.

@rnewman
Copy link
Collaborator

rnewman commented Feb 23, 2017

This is fine. I kinda dislike error_chain; it's obtuse, but so it goes.

@rnewman
Copy link
Collaborator

rnewman commented Feb 23, 2017

Err… now I can't mark this as approved. Well done, GitHub.

The idea is to separate the transaction applying code, which is
schema-aware, from the concrete storage code, which is just concerned
with getting bits onto disk.
This is part of a larger separation of the volatile PartitionMap,
which is modified every transaction, from the stable Schema, which is
infrequently modified.
This makes it easy to use Rc<Schema> or Arc<Schema> without inserting
&* sigils throughout the code.
This fails right now, because we allocate tx IDs even when we shouldn't.
This can be simplified when
Marwes/combine#86 makes it to a published
release, but this unblocks us for now.  This converts the `combine`
error type `ParseError<&'a [edn::Value]>` to a type with owned
`Vec<edn::Value>` collections, re-using `edn::Value::Vector` for
making them `Display`.
There are a few things to point out here:

- the fine grained error types have been flattened into one crate-wide
  error type; it's pretty easy to regain the granularity as needed.

- edn::ParseError is automatically lifted to
  mentat_query_parser::errors::Error;

- we use mentat_parser_utils::ValueParser to maintain parsing error
  information from `combine`.
ncalexan added a commit that referenced this pull request Feb 24, 2017
…#328. r=rnewman (#341)

* Pre: Drop unneeded tx0 from search results.

* Pre: Don't require a schema in some of the DB code.

The idea is to separate the transaction applying code, which is
schema-aware, from the concrete storage code, which is just concerned
with getting bits onto disk.

* Pre: Only reference Schema, not DB, in debug module.

This is part of a larger separation of the volatile PartitionMap,
which is modified every transaction, from the stable Schema, which is
infrequently modified.

* Pre: Fix indentation.

* Extract part of DB to new SchemaTypeChecking trait.

* Extract part of DB to new PartitionMapping trait.

* Pre: Don't expect :db.part/tx partition to advance when tx fails.

This fails right now, because we allocate tx IDs even when we shouldn't.

* Sketch a db interface without DB.

* Add ValueParseError; use error-chain in tx-parser.

This can be simplified when
Marwes/combine#86 makes it to a published
release, but this unblocks us for now.  This converts the `combine`
error type `ParseError<&'a [edn::Value]>` to a type with owned
`Vec<edn::Value>` collections, re-using `edn::Value::Vector` for
making them `Display`.

* Pre: Accept Borrow<Schema> instead of just &Schema in debug module.

This makes it easy to use Rc<Schema> or Arc<Schema> without inserting
&* sigils throughout the code.

* Use error-chain in query-parser.

There are a few things to point out here:

- the fine grained error types have been flattened into one crate-wide
  error type; it's pretty easy to regain the granularity as needed.

- edn::ParseError is automatically lifted to
  mentat_query_parser::errors::Error;

- we use mentat_parser_utils::ValueParser to maintain parsing error
  information from `combine`.

* Patch up top-level.

* Review comment: Only `borrow()` once.
@ncalexan
Copy link
Member Author

Gah, force pushing a replacement since I made two typoes in the commit message.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants