After playing with the BDB port of the storage engine for a while now, I've begun to thing that some of the things that the storage engine is responsible for is duplicated in all storage engines. For example: EnsureDocumentEtagMatchInTransaction or EnsureNotLockedByTransaction. If the logic of these ever changes then changes to all storage engines have to be made. It seems like this logic should be pulled out of the storage engine and the storage engine should simply be responsible for getting the data. I was thinking something along the lines of:
class Document { public int MetadataSize { get } public int DocumentSize { get } public Guid Etag { get } public Guid LockedByTransaction { get } public string Key { get } public DateTime LastModifiedTime { get } public RavenJObject Metadata { get } public Stream DocumentStream { get }
}
Again this is just an example and we would have to look a little closer at the operations. Even a simple IDocumentStorageActions.AddDocument has tons of logic associated with verifying etags, checking for active transactions, this is complicated stuff and seems like it should be outside the storage engine.
On Friday, August 17, 2012 4:45:45 PM UTC-4, Michael Weber wrote:
> Ok -- I will switch over to that branch (for the facet changes as well, > and issue a new pull request).
> It looks like there is a way to do partial writes in BDB. I will try to > figure out how to integrate it with c# streams.
> On Friday, August 17, 2012 3:56:47 PM UTC-4, Oren Eini wrote:
>> Please use the one from my fork, github.com/ayende/ravendb >> The 1.2 branch
>> On Fri, Aug 17, 2012 at 10:15 PM, Michael Weber <mtw...@gmail.com> wrote:
>>> I don't know about streaming yet with respect to BDB, all examples seems >>> to be full-buffer, but I will have to do more research to figure out >>> streaming writing.
>>> Yes, I am using the codecs, the code in that post is out-dated.
>>>>>> On Friday, 17 August 2012 11:27:09 UTC+1, Itamar Syn-Hershko wrote:
>>>>>>> A while back I did some reading on LevelDB and it seemed to be a >>>>>>> better fit, and a more stable option. Worth comparing the two, especially >>>>>>> in a multi-threaded scenarios.
>>>>>>> On Fri, Aug 17, 2012 at 7:07 AM, Michael Weber <mtw...@gmail.com>wrote:
>>>>>>>> Just a heads up that I have started hacking the storage engine for >>>>>>>> use with BDB. I have gotten it to the point of being able to store a >>>>>>>> document and retrieve it, but that is about it, there's obviously quite a >>>>>>>> lot left to do, but it's a start. I am using Berkeley DB for .NET ( >>>>>>>> http://sourceforge.net/**projec**ts/libdb-dotnet/<http://sourceforge.net/projects/libdb-dotnet/>) >>>>>>>> as the .net interface to the native dll. It's a BSD licence, so I hope >>>>>>>> that's compatible with RavenDB.
>>>>>>>> On Thursday, August 16, 2012 1:03:28 PM UTC-4, Michael Weber wrote:
>>>>>>>>> ah, got it
>>>>>>>>> On Thursday, August 16, 2012 12:57:03 PM UTC-4, Oren Eini wrote:
>>>>>>>>>> It is thread safe in the sense that it won't corrupt your data. >>>>>>>>>> It isn't using thread properly because it is basically using >>>>>>>>>> locks all over the place.
>>>>>>>>>> On Thu, Aug 16, 2012 at 7:55 PM, Michael Weber <mtw...@gmail.com>wrote:
>>>>>>>>>>> That's originally what I thought as well, but from their faq.
>>>>>>>>>>> "SQLite is threadsafe. We make this concession since many users >>>>>>>>>>> choose to ignore the advice given in the previous paragraph. But in order >>>>>>>>>>> to be thread-safe, SQLite must be compiled with the SQLITE_THREADSAFE >>>>>>>>>>> preprocessor macro set to 1. Both the Windows and Linux precompiled >>>>>>>>>>> binaries in the distribution are compiled this way. If you are unsure if >>>>>>>>>>> the SQLite library you are linking against is compiled to be threadsafe you >>>>>>>>>>> can call the sqlite3_threadsafe() interface to find out."
>>>>>>>>>>> On Thursday, August 16, 2012 12:35:46 PM UTC-4, Oren Eini wrote:
>>>>>>>>>>>> On Thu, Aug 16, 2012 at 7:33 PM, Michael Weber < >>>>>>>>>>>> mtw...@gmail.com> wrote:
>>>>>>>>>>>>> Is there a reason that transactional storage couldn't be built >>>>>>>>>>>>> upon sqlite instead of bdb. It seems like bdb is so low-level as to make >>>>>>>>>>>>> the port much harder.
>>>>>>>>>>>>> mike
>>>>>>>>>>>>> On Sunday, June 24, 2012 9:59:01 AM UTC-4, Oren Eini wrote:
>>>>>>>>>>>>>> Agree, let us know if you need any help
>>>>>>>>>>>>>> On Sun, Jun 24, 2012 at 4:37 PM, clayton collie < >>>>>>>>>>>>>> gbo...@gmail.com> wrote:
>>>>>>>>>>>>>>> May make for some interesting weekend hacking !!
>>>>>>>>>>>>>>> On Sun, Jun 24, 2012 at 12:39 AM, Oren Eini (Ayende Rahien) >>>>>>>>>>>>>>> <aye...@ayende.com> wrote:
>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> We intend to do major work on that post 1.2
>>>>>>>>>>>>>>>> If anyone wants to jump in, the major pieces would be >>>>>>>>>>>>>>>> building a transactional storage on top of BDB and then just testing.
>>>>>>>>>>>>>>>> On Sat, Jun 23, 2012 at 11:46 PM, clayton collie < >>>>>>>>>>>>>>>> gbo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> Is there any movement on this. I really want to use Raven, >>>>>>>>>>>>>>>>> but everything else in my infrastructure(rabbit, redis, etc) are geared >>>>>>>>>>>>>>>>> toward linux.
>>>>>>>>>>>>>>>>> On Tuesday, May 22, 2012 9:54:26 AM UTC-4, Beaker wrote:
>>>>>>>>>>>>>>>>>> There's only two ravenDB calls in the stack trace. I'll >>>>>>>>>>>>>>>>>> run them and >>>>>>>>>>>>>>>>>> display -> I think I'm just going to need to step through >>>>>>>>>>>>>>>>>> the code to >>>>>>>>>>>>>>>>>> get to the root of the problem. I think at the heart of >>>>>>>>>>>>>>>>>> this is going >>>>>>>>>>>>>>>>>> to be some small fundamental difference between how mono >>>>>>>>>>>>>>>>>> and .NET >>>>>>>>>>>>>>>>>> actually implement the MEF structure.
>>>>>>>>>>>>>>>>>> On May 22, 9:12 am, "Oren Eini (Ayende Rahien)" < >>>>>>>>>>>>>>>>>> aye...@ayende.com> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> > This indicate that MEF had some issue, tried to throw >>>>>>>>>>>>>>>>>> an error, then threw >>>>>>>>>>>>>>>>>> > an error trying to throw an error. >>>>>>>>>>>>>>>>>> http://lists.ximian.com/************ >>>>>>>>>>>>>>>>>> pipermail/mono-bugs/2011-June/************112020.html<http://lists.ximian.com/pipermail/mono-bugs/2011-June/112020.html>
>>>>>>>>>>>>>>>>>> > You need to look at the stack trace of the error to see >>>>>>>>>>>>>>>>>> if you can figure >>>>>>>>>>>>>>>>>> > out what is wrong there.
>>>>>>>>>>>>>>>>>> > On Tue, May 22, 2012 at 2:43 PM, Beaker < >>>>>>>>>>>>>>>>>> dstrohsch...@gmail.com> wrote: >>>>>>>>>>>>>>>>>> > > I know it's been done before, and I can see chunks of >>>>>>>>>>>>>>>>>> code in the git >>>>>>>>>>>>>>>>>> > > repo where Mono is taken into consideration, but >>>>>>>>>>>>>>>>>> something is evading >>>>>>>>>>>>>>>>>> > > me.
>>>>>>>>>>>>>>>>>> > > I have the latest stable Mono release, latest stable >>>>>>>>>>>>>>>>>> Mono Develop, and
There are some utility functions there that are used, but most of the time,
those things are _really_ tied to the internal of how the storage engine
actually does things.
On Sun, Aug 19, 2012 at 3:06 AM, Michael Weber <mtwe...@gmail.com> wrote:
> Oren,
> After playing with the BDB port of the storage engine for a while now,
> I've begun to thing that some of the things that the storage engine is
> responsible for is duplicated in all storage engines. For
> example: EnsureDocumentEtagMatchInTransaction
> or EnsureNotLockedByTransaction. If the logic of these ever changes then
> changes to all storage engines have to be made. It seems like this logic
> should be pulled out of the storage engine and the storage engine should
> simply be responsible for getting the data. I was thinking something along
> the lines of:
> class Document {
> public int MetadataSize { get }
> public int DocumentSize { get }
> public Guid Etag { get }
> public Guid LockedByTransaction { get }
> public string Key { get }
> public DateTime LastModifiedTime { get }
> public RavenJObject Metadata { get }
> public Stream DocumentStream { get }
> }
> Again this is just an example and we would have to look a little closer at
> the operations. Even a simple IDocumentStorageActions.AddDocument has tons
> of logic associated with verifying etags, checking for active transactions,
> this is complicated stuff and seems like it should be outside the storage
> engine.
> mike
> On Friday, August 17, 2012 4:45:45 PM UTC-4, Michael Weber wrote:
>> Ok -- I will switch over to that branch (for the facet changes as well,
>> and issue a new pull request).
>> It looks like there is a way to do partial writes in BDB. I will try to
>> figure out how to integrate it with c# streams.
>> On Friday, August 17, 2012 3:56:47 PM UTC-4, Oren Eini wrote:
>>> Please use the one from my fork, github.com/ayende/ravendb
>>> The 1.2 branch
>>> On Fri, Aug 17, 2012 at 10:15 PM, Michael Weber <mtw...@gmail.com>wrote:
>>>> I don't know about streaming yet with respect to BDB, all examples
>>>> seems to be full-buffer, but I will have to do more research to figure out
>>>> streaming writing.
>>>> Yes, I am using the codecs, the code in that post is out-dated.
>>>> On Friday, August 17, 2012 2:48:30 PM UTC-4, Oren Eini wrote:
>>>>> Regarding your blog post.
>>>>> Note that actually saving to disk is a bit more complex than that.
>>>>> We no longer do things like this:
>>>>> using(var ms = new MemoryStream()) { data.WriteTo(ms); dataBuffer =
>>>>> ms.ToArray(); }
>>>>> We have users that uses documents that are several MB in size, and we
>>>>> have to stream it to disk, instead of copying the data several times.
>>>>> Also, you aren't using codecs here, which are required so we can use
>>>>> things like encryption & compression.
>>>>> Also, what build are you working off?
>>>>> On Fri, Aug 17, 2012 at 9:36 PM, Oren Eini (Ayende Rahien) <
>>>>> aye...@ayende.com> wrote:
>>>>>> I already implemented transactions for Munin, that was... touchy.
>>>>>> It is something that I would like to avoid.
>>>>>> On Fri, Aug 17, 2012 at 7:17 PM, Matt Warren <matt...@gmail.com>wrote:
>>>>>>> I also spent a bit of time looking at LevelDB
>>>>>>> On Friday, 17 August 2012 11:27:09 UTC+1, Itamar Syn-Hershko wrote:
>>>>>>>> A while back I did some reading on LevelDB and it seemed to be a
>>>>>>>> better fit, and a more stable option. Worth comparing the two, especially
>>>>>>>> in a multi-threaded scenarios.
>>>>>>>> On Fri, Aug 17, 2012 at 7:07 AM, Michael Weber <mtw...@gmail.com>wrote:
>>>>>>>>> Just a heads up that I have started hacking the storage engine for
>>>>>>>>> use with BDB. I have gotten it to the point of being able to store a
>>>>>>>>> document and retrieve it, but that is about it, there's obviously quite a
>>>>>>>>> lot left to do, but it's a start. I am using Berkeley DB for .NET (
>>>>>>>>> http://sourceforge.net/**projec****ts/libdb-dotnet/<http://sourceforge.net/projects/libdb-dotnet/>)
>>>>>>>>> as the .net interface to the native dll. It's a BSD licence, so I hope
>>>>>>>>> that's compatible with RavenDB.
>>>>>>>>> On Thursday, August 16, 2012 1:03:28 PM UTC-4, Michael Weber
>>>>>>>>> wrote:
>>>>>>>>>> ah, got it
>>>>>>>>>> On Thursday, August 16, 2012 12:57:03 PM UTC-4, Oren Eini wrote:
>>>>>>>>>>> It is thread safe in the sense that it won't corrupt your data.
>>>>>>>>>>> It isn't using thread properly because it is basically using
>>>>>>>>>>> locks all over the place.
>>>>>>>>>>> On Thu, Aug 16, 2012 at 7:55 PM, Michael Weber <mtw...@gmail.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>> That's originally what I thought as well, but from their faq.
>>>>>>>>>>>> "SQLite is threadsafe. We make this concession since many users
>>>>>>>>>>>> choose to ignore the advice given in the previous paragraph. But in order
>>>>>>>>>>>> to be thread-safe, SQLite must be compiled with the SQLITE_THREADSAFE
>>>>>>>>>>>> preprocessor macro set to 1. Both the Windows and Linux precompiled
>>>>>>>>>>>> binaries in the distribution are compiled this way. If you are unsure if
>>>>>>>>>>>> the SQLite library you are linking against is compiled to be threadsafe you
>>>>>>>>>>>> can call the sqlite3_threadsafe() interface to find out."
>>>>>>>>>>>> On Thursday, August 16, 2012 12:35:46 PM UTC-4, Oren Eini
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On Thu, Aug 16, 2012 at 7:33 PM, Michael Weber <
>>>>>>>>>>>>> mtw...@gmail.com> wrote:
>>>>>>>>>>>>>> Is there a reason that transactional storage couldn't be
>>>>>>>>>>>>>> built upon sqlite instead of bdb. It seems like bdb is so low-level as to
>>>>>>>>>>>>>> make the port much harder.
>>>>>>>>>>>>>> mike
>>>>>>>>>>>>>> On Sunday, June 24, 2012 9:59:01 AM UTC-4, Oren Eini wrote:
>>>>>>>>>>>>>>> Agree, let us know if you need any help
>>>>>>>>>>>>>>> On Sun, Jun 24, 2012 at 4:37 PM, clayton collie <
>>>>>>>>>>>>>>> gbo...@gmail.com> wrote:
>>>>>>>>>>>>>>>> May make for some interesting weekend hacking !!
>>>>>>>>>>>>>>>> On Sun, Jun 24, 2012 at 12:39 AM, Oren Eini (Ayende
>>>>>>>>>>>>>>>> Rahien) <aye...@ayende.com> wrote:
>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>> We intend to do major work on that post 1.2
>>>>>>>>>>>>>>>>> If anyone wants to jump in, the major pieces would be
>>>>>>>>>>>>>>>>> building a transactional storage on top of BDB and then just testing.
>>>>>>>>>>>>>>>>> On Sat, Jun 23, 2012 at 11:46 PM, clayton collie <
>>>>>>>>>>>>>>>>> gbo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> Is there any movement on this. I really want to use
>>>>>>>>>>>>>>>>>> Raven, but everything else in my infrastructure(rabbit, redis, etc) are
>>>>>>>>>>>>>>>>>> geared toward linux.
>>>>>>>>>>>>>>>>>> On Tuesday, May 22, 2012 9:54:26 AM UTC-4, Beaker wrote:
>>>>>>>>>>>>>>>>>>> There's only two ravenDB calls in the stack trace. I'll
>>>>>>>>>>>>>>>>>>> run them and
>>>>>>>>>>>>>>>>>>> display -> I think I'm just going to need to step
>>>>>>>>>>>>>>>>>>> through the code to
>>>>>>>>>>>>>>>>>>> get to the root of the problem. I think at the heart of
>>>>>>>>>>>>>>>>>>> this is going
>>>>>>>>>>>>>>>>>>> to be some small fundamental difference between how mono
>>>>>>>>>>>>>>>>>>> and .NET
>>>>>>>>>>>>>>>>>>> actually implement the MEF structure.
>>>>>>>>>>>>>>>>>>> On May 22, 9:12 am, "Oren Eini (Ayende Rahien)" <
>>>>>>>>>>>>>>>>>>> aye...@ayende.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> > This indicate that MEF had some issue, tried to throw
>>>>>>>>>>>>>>>>>>> an error, then threw
>>>>>>>>>>>>>>>>>>> > an error trying to throw an error.
>>>>>>>>>>>>>>>>>>> http://lists.ximian.com/************** >>>>>>>>>>>>>>>>>>> pipermail/mono-bugs/2011-June/**************112020.html<http://lists.ximian.com/pipermail/mono-bugs/2011-June/112020.html>
>>>>>>>>>>>>>>>>>>> > You need to look at the stack trace of the error
>> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>>> -- >> You received this message because you are subscribed to the Google Groups >> "ravendb" group.
>> To unsubscribe from this group and stop receiving emails from it, send an >> email to ravendb+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ravendb" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ravendb+u...@**googlegroups.com.
>> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>>>> El sábado, 9 de febrero de 2013 08:38:38 UTC-5, Michael Weber escribió:
>>>>> It's not 100% dead, it was waiting on Oren to finish the final push >>>>> for 2.0. But it now looks like he may have other ideas for mono support.
>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ravendb" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to ravendb+u...@**googlegroups.com.
>>> -- >> You received this message because you are subscribed to the Google Groups >> "ravendb" group.
>> To unsubscribe from this group and stop receiving emails from it, send an >> email to ravendb+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
Only question, from a brief look at the API, is whether streaming/chunking is possible for large values. Didn't want to download the whole kit and kaboodle to find out.
El miércoles, 13 de febrero de 2013 17:42:27 UTC-5, Matt Johnson escribió:
> BangDB looks pretty awesome, but it's pure C++. We would have to write > our own managed wrapper assembly (C++/CLI). BerkeleyDB already has a C# > API.
> Given the choice, I'd still go for BangDB - but there's certainly more > work involved.
> On Wednesday, February 13, 2013 2:48:20 PM UTC-7, Oren Eini wrote:
>> No idea to all questions.
>> On Wed, Feb 13, 2013 at 11:42 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>> Just read the link on BangDB. How would its performance match up to >>> Esent. Would it be faster, and would it still be ACID?
>>> On Sunday, February 10, 2013 4:01:45 AM UTC-5, Oren Eini wrote:
>>>> That looks nice, yes.
>>>> On Sat, Feb 9, 2013 at 4:57 PM, clayton collie <gbo...@gmail.com>wrote:
>>>>> El sábado, 9 de febrero de 2013 08:38:38 UTC-5, Michael Weber >>>>> escribió:
>>>>>> It's not 100% dead, it was waiting on Oren to finish the final push >>>>>> for 2.0. But it now looks like he may have other ideas for mono support.
>>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ravendb" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to ravendb+u...@**googlegroups.com.
>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "ravendb" group.
>>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to ravendb+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
Matt,
From the time that I deal with BDB C# API.
It was like swimming in the sewers.
Just to give you some ideas, The _esent_ managed library had a bunch of
bugs in it that we discovered early on.
I shudder to think what is the current status there.
On Thu, Feb 14, 2013 at 12:42 AM, Matt Johnson <mj1...@hotmail.com> wrote:
> BangDB looks pretty awesome, but it's pure C++. We would have to write
> our own managed wrapper assembly (C++/CLI). BerkeleyDB already has a C#
> API.
> Given the choice, I'd still go for BangDB - but there's certainly more
> work involved.
> On Wednesday, February 13, 2013 2:48:20 PM UTC-7, Oren Eini wrote:
>> No idea to all questions.
>> On Wed, Feb 13, 2013 at 11:42 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>> Just read the link on BangDB. How would its performance match up to
>>> Esent. Would it be faster, and would it still be ACID?
>>> On Sunday, February 10, 2013 4:01:45 AM UTC-5, Oren Eini wrote:
>>>> That looks nice, yes.
>>>> On Sat, Feb 9, 2013 at 4:57 PM, clayton collie <gbo...@gmail.com>wrote:
>>>>> El sábado, 9 de febrero de 2013 08:38:38 UTC-5, Michael Weber
>>>>> escribió:
>>>>>> It's not 100% dead, it was waiting on Oren to finish the final push
>>>>>> for 2.0. But it now looks like he may have other ideas for mono support.
>>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ravendb" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to ravendb+u...@**googlegroups.com.
>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "ravendb" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to ravendb+u...@**googlegroups.com.
>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>> .
>> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
On Thu, Feb 14, 2013 at 12:46 AM, clayton collie <gbo...@gmail.com> wrote:
> Only question, from a brief look at the API, is whether streaming/chunking
> is possible for large values. Didn't want to download the whole kit and
> kaboodle to find out.
> El miércoles, 13 de febrero de 2013 17:42:27 UTC-5, Matt Johnson escribió:
>> BangDB looks pretty awesome, but it's pure C++. We would have to write
>> our own managed wrapper assembly (C++/CLI). BerkeleyDB already has a C#
>> API.
>> Given the choice, I'd still go for BangDB - but there's certainly more
>> work involved.
>> On Wednesday, February 13, 2013 2:48:20 PM UTC-7, Oren Eini wrote:
>>> No idea to all questions.
>>> On Wed, Feb 13, 2013 at 11:42 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
>>>> Just read the link on BangDB. How would its performance match up to
>>>> Esent. Would it be faster, and would it still be ACID?
>>>> On Sunday, February 10, 2013 4:01:45 AM UTC-5, Oren Eini wrote:
>>>>> That looks nice, yes.
>>>>> On Sat, Feb 9, 2013 at 4:57 PM, clayton collie <gbo...@gmail.com>wrote:
>>>>>> El sábado, 9 de febrero de 2013 08:38:38 UTC-5, Michael Weber
>>>>>> escribió:
>>>>>>> It's not 100% dead, it was waiting on Oren to finish the final push
>>>>>>> for 2.0. But it now looks like he may have other ideas for mono support.
>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "ravendb" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to ravendb+u...@**googlegroups.com.
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "ravendb" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to ravendb+u...@googlegroups.com.
>>>> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
>>>> .
>>> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
From the docu on that site it seams to always return the whole data
blob/chunk when one calls the get method. But perhaps the docu is not
thorough or not up-to-date with its current state.
// Ryan
Sent from my iPhone
On Thursday, February 14, 2013, Oren Eini (Ayende Rahien) wrote:
> On Thu, Feb 14, 2013 at 12:46 AM, clayton collie <gbo...@gmail.com> wrote:
> Only question, from a brief look at the API, is whether streaming/chunking
> is possible for large values. Didn't want to download the whole kit and
> kaboodle to find out.
> El miércoles, 13 de febrero de 2013 17:42:27 UTC-5, Matt Johnson escribió:
> BangDB looks pretty awesome, but it's pure C++. We would have to write
> our own managed wrapper assembly (C++/CLI). BerkeleyDB already has a C#
> API.
> Given the choice, I'd still go for BangDB - but there's certainly more
> work involved.
> On Wednesday, February 13, 2013 2:48:20 PM UTC-7, Oren Eini wrote:
> No idea to all questions.
> On Wed, Feb 13, 2013 at 11:42 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
> Just read the link on BangDB. How would its performance match up to Esent.
> Would it be faster, and would it still be ACID?
> On Sunday, February 10, 2013 4:01:45 AM UTC-5, Oren Eini wrote:
> That looks nice, yes.
> On Sat, Feb 9, 2013 at 4:57 PM, clayton collie <gbo...@gmail.com> wrote:
> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+u...@**googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+u...@googlegroups.com.
> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group a
> Matt,
> From the time that I deal with BDB C# API.
> It was like swimming in the sewers.
> Just to give you some ideas, The _esent_ managed library had a bunch of
> bugs in it that we discovered early on.
> I shudder to think what is the current status there.
> On Thu, Feb 14, 2013 at 12:42 AM, Matt Johnson <mj1...@hotmail.com> wrote:
> BangDB looks pretty awesome, but it's pure C++. We would have to write
> our own managed wrapper assembly (C++/CLI). BerkeleyDB already has a C#
> API.
> Given the choice, I'd still go for BangDB - but there's certainly more
> work involved.
> On Wednesday, February 13, 2013 2:48:20 PM UTC-7, Oren Eini wrote:
> No idea to all questions.
> On Wed, Feb 13, 2013 at 11:42 PM, Khalid Abuhakmeh <bird...@gmail.com>wrote:
> Just read the link on BangDB. How would its performance match up to Esent.
> Would it be faster, and would it still be ACID?
> On Sunday, February 10, 2013 4:01:45 AM UTC-5, Oren Eini wrote:
> That looks nice, yes.
> On Sat, Feb 9, 2013 at 4:57 PM, clayton collie <gbo...@gmail.com> wrote:
> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+u...@**googlegroups.com.
> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+u...@**googlegroups.com.
> For more options, visit https://groups.google.com/**groups/opt_out<https://groups.google.com/groups/opt_out>
> .
> --
> You received this message because you are subscribed to the Google Groups
> "ravendb" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ravendb+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
