isEmbedded() expose what sort of contract the leveldown can provide.

[dominictarr]

After seeing a talk at nodeconf eu that used sqldown I realized it would be impossible to stop people using levelup with non-embedded back ends, and having a discussion of this #255 scale every time would only turn me into a grumpy old bastard...

Then I realized there was a simpler possibility, we add an db.isEmbedded() method this would be exposed on the levelup and leveldown instances, and modules that do not support non-embedded databases can throw with a helpful error message (that links to documentation on the distinction between embedded and service databases)

Also, there would be documentation on isEmbedded() and it would be easy to do a few pull requests to add isEmbedded to the various leveldowns. So it would be simpler than reimplementing all of level #270 (this will take a long time, anyway) but still allow people using level in other ways, such as @nlf @adambrault @fritzy are doing.

[nlf]

👍

Seems reasonable to me.

Something @fritzy had brought up in the past was adding some kind of feature detection to *down backends, so this could potentially lay the groundwork for future development in that direction as well.

[mcollina]

As discussed at nodeconfeu, 👍 for me.

[juliangruber]

+1 to the general idea, embedded is the wrong word though isn't it? couldn't a non-embedded db support all of abstract-leveldown?

[dominictarr]

@juliangruber yes, but it wouldn't support the implicit assumption of embeddedness - that all incoming data passes through this instance.
So, live streams and prehooks (which are the basis of many modules) do not work in non-embedded databases.

[juliangruber]

ah ok. agreed, this is good to know. thinking about future demands we could simplify by implementing a broader compatibility function, like:

db.has('embedded')
db.has('snapshots')
db.has('batches')

etc

[heapwolf]

+1 to Julian's suggestion!

On Saturday, September 13, 2014, Julian Gruber notifications@github.com
wrote:

ah ok. agreed, this is good to know. thinking about future demands we
could simplify by implementing a broader compatibility function, like:

db.has('embedded')db.has('snapshots')db.has('batches')

etc

—
Reply to this email directly or view it on GitHub
#279 (comment).

Paolo Fragomeni
Founder, Here is How
http://hereishow.to

github.com/hij1nx
twitter.com/hij1nx

[dominictarr]

Or just db.supports[feature] ? and then that feature should probably throw if you try and use it.

[juliangruber]

yeah, the exact api is probably best discussed in a pr. but big +1 to the idea

[nolanlawson]

+1 for Julian's idea. It would also be nice if the abstract-leveldown tests checked for such things before running certain tests, e.g. for the snapshot test.

[juliangruber]

...and if we had a module that takes those compatibility results and generates a big badge for readmes and a small one for the levelup wiki

[nolanlawson]

+1000

[calvinmetcalf]

taking a step back what is the isEmbedded supposed to check for, that only one process can connect to it at once?

because sqlite3 is embedded, but it can have multiple processes have it open which work screw up the ability to use sublevel

[dominictarr]

@calvinmetcalf good point... maybe it should be isSingleProcess ?
Although, that sounds like it could be true when only one process happens to be connected...

So we want to know if the backend is strictly single process... this is more important than being embedded, per se.

Although, this is often implied by being embedded...

[mcollina]

isEmbedded looks nicer. But I get the point of isSingleProcess.

How about hasExclusiveAccess?