Update roadmap
This commit is contained in:
parent
7a70b2ae94
commit
556ca85d43
3 changed files with 22 additions and 73 deletions
35
README.md
35
README.md
|
@ -585,35 +585,16 @@ Existing APIs (TBD)
|
||||||
<ul>
|
<ul>
|
||||||
<li>
|
<li>
|
||||||
<p>
|
<p>
|
||||||
<tt>new/2</tt> - automatically detect and prevent multiple callers of the
|
<tt>delete/1</tt>
|
||||||
same Erlang virtual machine from simultaneously opening the same
|
(<a href="http://code.google.com/p/leveldb/issues/detail?id=48">http://code.google.com/p/leveldb/issues/detail?id=48</a>)
|
||||||
LevelDB. Excerpt from the Google leveldb mailing list:
|
|
||||||
<br>
|
|
||||||
</p>
|
</p>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
<li>
|
||||||
|
<p>
|
||||||
|
<tt>new/2</tt> -
|
||||||
|
(<a href="http://code.google.com/p/leveldb/issues/detail?id=49">http://code.google.com/p/leveldb/issues/detail?id=49</a>)
|
||||||
|
</p>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
|
||||||
|
|
||||||
|
|
||||||
<pre><tt>Sanjay Ghemawat
|
|
||||||
View profile
|
|
||||||
More options Sep 30, 1:04 am
|
|
||||||
On Thu, Sep 29, 2011 at 8:30 AM, Joseph Wayne Norton wrote:
|
|
||||||
> Hans -
|
|
||||||
> Thanks. Is is correct to assume that it is the caller's responsibility to
|
|
||||||
> ensure this does not happen?
|
|
||||||
|
|
||||||
leveldb guarantees that it will catch when two distinct processes
|
|
||||||
try to open the db concurrently. However it doesn't guarantee what happens
|
|
||||||
if the same process tries to do so and therefore it is the caller's
|
|
||||||
responsibility
|
|
||||||
to check for concurrent opens from the same process.
|
|
||||||
This is ugly, but the unix file locking primitives are very annoying in
|
|
||||||
this regard. I'll think about whether or not we should clean up the spec
|
|
||||||
by doing extra checks inside the leveldb implementation.</tt></pre>
|
|
||||||
|
|
||||||
<ul>
|
|
||||||
<li>
|
<li>
|
||||||
<p>
|
<p>
|
||||||
<tt>new/2</tt> - investigate if LevelDB's snapshot feature is useful (or
|
<tt>new/2</tt> - investigate if LevelDB's snapshot feature is useful (or
|
||||||
|
@ -634,6 +615,8 @@ consider adding explicit read_options and write_options for LET's
|
||||||
</p>
|
</p>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -585,35 +585,16 @@ Existing APIs (TBD)
|
||||||
<ul>
|
<ul>
|
||||||
<li>
|
<li>
|
||||||
<p>
|
<p>
|
||||||
<tt>new/2</tt> - automatically detect and prevent multiple callers of the
|
<tt>delete/1</tt>
|
||||||
same Erlang virtual machine from simultaneously opening the same
|
(<a href="http://code.google.com/p/leveldb/issues/detail?id=48">http://code.google.com/p/leveldb/issues/detail?id=48</a>)
|
||||||
LevelDB. Excerpt from the Google leveldb mailing list:
|
|
||||||
<br>
|
|
||||||
</p>
|
</p>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
<li>
|
||||||
|
<p>
|
||||||
|
<tt>new/2</tt> -
|
||||||
|
(<a href="http://code.google.com/p/leveldb/issues/detail?id=49">http://code.google.com/p/leveldb/issues/detail?id=49</a>)
|
||||||
|
</p>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
|
||||||
|
|
||||||
|
|
||||||
<pre><tt>Sanjay Ghemawat
|
|
||||||
View profile
|
|
||||||
More options Sep 30, 1:04 am
|
|
||||||
On Thu, Sep 29, 2011 at 8:30 AM, Joseph Wayne Norton wrote:
|
|
||||||
> Hans -
|
|
||||||
> Thanks. Is is correct to assume that it is the caller's responsibility to
|
|
||||||
> ensure this does not happen?
|
|
||||||
|
|
||||||
leveldb guarantees that it will catch when two distinct processes
|
|
||||||
try to open the db concurrently. However it doesn't guarantee what happens
|
|
||||||
if the same process tries to do so and therefore it is the caller's
|
|
||||||
responsibility
|
|
||||||
to check for concurrent opens from the same process.
|
|
||||||
This is ugly, but the unix file locking primitives are very annoying in
|
|
||||||
this regard. I'll think about whether or not we should clean up the spec
|
|
||||||
by doing extra checks inside the leveldb implementation.</tt></pre>
|
|
||||||
|
|
||||||
<ul>
|
|
||||||
<li>
|
<li>
|
||||||
<p>
|
<p>
|
||||||
<tt>new/2</tt> - investigate if LevelDB's snapshot feature is useful (or
|
<tt>new/2</tt> - investigate if LevelDB's snapshot feature is useful (or
|
||||||
|
@ -634,6 +615,8 @@ consider adding explicit read_options and write_options for LET's
|
||||||
</p>
|
</p>
|
||||||
</li>
|
</li>
|
||||||
</ul>
|
</ul>
|
||||||
|
</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -282,28 +282,11 @@ $ erl -smp +A 5 -pz ../../sext/ebin -pz ../../qc/ebin
|
||||||
(http://code.google.com/p/leveldb/issues/detail?id=43)
|
(http://code.google.com/p/leveldb/issues/detail?id=43)
|
||||||
|
|
||||||
- Existing APIs (TBD)
|
- Existing APIs (TBD)
|
||||||
* +new/2+ - automatically detect and prevent multiple callers of the
|
* +delete/1+
|
||||||
same Erlang virtual machine from simultaneously opening the same
|
(http://code.google.com/p/leveldb/issues/detail?id=48)
|
||||||
LevelDB. Excerpt from the Google leveldb mailing list:
|
|
||||||
+
|
|
||||||
------
|
|
||||||
Sanjay Ghemawat
|
|
||||||
View profile
|
|
||||||
More options Sep 30, 1:04 am
|
|
||||||
On Thu, Sep 29, 2011 at 8:30 AM, Joseph Wayne Norton wrote:
|
|
||||||
> Hans -
|
|
||||||
> Thanks. Is is correct to assume that it is the caller's responsibility to
|
|
||||||
> ensure this does not happen?
|
|
||||||
|
|
||||||
leveldb guarantees that it will catch when two distinct processes
|
* +new/2+ -
|
||||||
try to open the db concurrently. However it doesn't guarantee what happens
|
(http://code.google.com/p/leveldb/issues/detail?id=49)
|
||||||
if the same process tries to do so and therefore it is the caller's
|
|
||||||
responsibility
|
|
||||||
to check for concurrent opens from the same process.
|
|
||||||
This is ugly, but the unix file locking primitives are very annoying in
|
|
||||||
this regard. I'll think about whether or not we should clean up the spec
|
|
||||||
by doing extra checks inside the leveldb implementation.
|
|
||||||
------
|
|
||||||
|
|
||||||
* +new/2+ - investigate if LevelDB\'s snapshot feature is useful (or
|
* +new/2+ - investigate if LevelDB\'s snapshot feature is useful (or
|
||||||
not) for LETS
|
not) for LETS
|
||||||
|
|
Loading…
Reference in a new issue