Getting started, got a question
Daniel
exploring then internals of this and creating doc objects in my store
I realized something. I don't see a way to delete a document from a
store. Am I missing this or is it not implemented yet?
Good job and keep up the work.
Daniel
Yurii Rashkovskii
On Apr 3, 2008, at 4:21 AM, Daniel wrote:
>
> Starting to tinker, specifically with the console right now. As I was
> exploring then internals of this and creating doc objects in my store
> I realized something. I don't see a way to delete a document from a
> store. Am I missing this or is it not implemented yet?
>
Well, like I was explaining at EURUKO'08 conversations about StrokeDB,
that's kinda intentional. The primary StrokeDB's goal for now is
storing data, not deleting it. So that's why we still don't have
deletion functionality.
Though of course mostly everybody needs it.
Here's how we're going to get it implemented anytime soon:
We plan to implement document deletion by appending document with an
additional Deleted meta (with hardcoded UUID, just like Meta,
StoreInfo, Diff, etc.). This way we can easily add methods like
#undelete!
So, in order to delete document one will need to do something like
document.metas << Deleted (or we can implement a shortcut method for
that, like Document#delete!).
Once document is deleted and Deleted provides #undelete! method,
you'll be able to undelete as simple as document.undelete!
Makes sense?
Yurii.
Daniel
On Apr 2, 9:26 pm, Yurii Rashkovskii <yra...@gmail.com> wrote:
> Well, like I was explaining at EURUKO'08 conversations about StrokeDB,
> that's kinda intentional. The primary StrokeDB's goal for now is
> storing data, not deleting it. So that's why we still don't have
> deletion functionality.
code and the docs dir and then started tinkering in the console.
> Though of course mostly everybody needs it.
>
> Here's how we're going to get it implemented anytime soon:
>
> We plan to implement document deletion by appending document with an
> additional Deleted meta (with hardcoded UUID, just like Meta,
> StoreInfo, Diff, etc.). This way we can easily add methods like
> #undelete!
>
> So, in order to delete document one will need to do something like
> document.metas << Deleted (or we can implement a shortcut method for
> that, like Document#delete!).
> Once document is deleted and Deleted provides #undelete! method,
> you'll be able to undelete as simple as document.undelete!
>
> Makes sense?
Now let me pose this one to you and can provide a relevant analogy.
What of the scenario that you had to be able to guarantee that a
document and all it's revisions are purged for the data store aka
obliterated. I perfect analogy is with subversion, there is no
directly implemented way for you to obliterate a file once it has been
added to the repo. While the original thought is why would you ever
want to destroy your history, but now with all this Intellectual
Property junk if you had a violation in your repo. You will have to be
able to obliterate and provide assurance that it no longer exist in
the repo. This example may be extreme, but good example of unforeseen
exception to original design.
Daniel
Yurii Rashkovskii
> On Apr 2, 9:26 pm, Yurii Rashkovskii <yra...@gmail.com> wrote:
>> Well, like I was explaining at EURUKO'08 conversations about
>> StrokeDB,
>> that's kinda intentional. The primary StrokeDB's goal for now is
>> storing data, not deleting it. So that's why we still don't have
>> deletion functionality.
>
> I do apologize, I did not look over the presentation. Just read the
> code and the docs dir and then started tinkering in the console.
No matter, it wasn't in the presentation itself — just a stuff we've
been discussing on the conference party :)
>> Makes sense?
>
> Perfect sense.
>
>
> Now let me pose this one to you and can provide a relevant analogy.
> What of the scenario that you had to be able to guarantee that a
> document and all it's revisions are purged for the data store aka
> obliterated. I perfect analogy is with subversion, there is no
> directly implemented way for you to obliterate a file once it has been
> added to the repo. While the original thought is why would you ever
> want to destroy your history, but now with all this Intellectual
> Property junk if you had a violation in your repo. You will have to be
> able to obliterate and provide assurance that it no longer exist in
> the repo. This example may be extreme, but good example of unforeseen
> exception to original design.
Actually I see no real problem implementing total document
obliteration on top of the deletion mechanism proposed above. It is
just not that critical for me now so I am going to do just a simple
implementation of that Deleted stuff. Later on, after we'll have new
strorages API (new-storages branch, work in progress), we can add
something like #obliterate! method to Deleted meta which will clean
data from storages so there will be no document imprints. So basically
there is no problem or at least I don't see it.
Yurii.
Daniel
On Apr 2, 9:47 pm, Yurii Rashkovskii <yra...@gmail.com> wrote:
> Actually I see no real problem implementing total document
> obliteration on top of the deletion mechanism proposed above. It is
> just not that critical for me now so I am going to do just a simple
> implementation of that Deleted stuff. Later on, after we'll have new
> strorages API (new-storages branch, work in progress), we can add
> something like #obliterate! method to Deleted meta which will clean
> data from storages so there will be no document imprints. So basically
> there is no problem or at least I don't see it.
definitely understand it being lower priority to more important items
such as the storage API.