http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Vadi, What problem do you have with Esent? What do you mean, unawareness of exsitence and reliability. http://ayende.com/3912/designing-a-document-database-what-next#comment20http://ayende.com/3912/designing-a-document-database-what-next#comment20Fri, 20 Mar 2009 11:22:10 GMTFernando, From concept idea, they are very similar. From design perspective, there are a significant changes all around because of different design constraints regarding the implementation. http://ayende.com/3912/designing-a-document-database-what-next#comment19http://ayende.com/3912/designing-a-document-database-what-next#comment19Fri, 20 Mar 2009 11:18:15 GMTNuz, Not if you put me over hot coals and made me watch all the Drag & Drop demos in MSDN. http://ayende.com/3912/designing-a-document-database-what-next#comment18http://ayende.com/3912/designing-a-document-database-what-next#comment18Fri, 20 Mar 2009 11:15:05 GMTUriel, Maybe, but I lack the skills to do so. In addition to that, putting Erlang in the enterprise is not something that goes quickly or easily. I am running into problems just putting MSMQ into place, because it is an unfamiliar tech to the sys admins. Putting totally new platform has _high_ resistance. http://ayende.com/3912/designing-a-document-database-what-next#comment17http://ayende.com/3912/designing-a-document-database-what-next#comment17Fri, 20 Mar 2009 10:58:50 GMTI see one problem though is using Esent. It's the unawareness of existence and reliability. How could i just use my own preferred database server, eg., I could be interested in using SQL Server or Oracle, which solves lot of other problems like clustering, replication etc., Do you think to start this as a OSS project so that we can contribute one or two? http://ayende.com/3912/designing-a-document-database-what-next#comment16http://ayende.com/3912/designing-a-document-database-what-next#comment16Wed, 18 Mar 2009 11:11:03 GMTTravis, iMeta have provided a full time developer for 3 months. See here: [groups.google.com.ar/.../5111835e99d9a8e8?hl=en](http://groups.google.com.ar/group/nhibernate-development/msg/5111835e99d9a8e8?hl=en) http://ayende.com/3912/designing-a-document-database-what-next#comment15http://ayende.com/3912/designing-a-document-database-what-next#comment15Wed, 18 Mar 2009 08:47:46 GMTDid a company or someone step up for Linq to NHibernate? What was the outcome? http://ayende.com/3912/designing-a-document-database-what-next#comment14http://ayende.com/3912/designing-a-document-database-what-next#comment14Tue, 17 Mar 2009 19:01:40 GMTSimon, The main reason that Rhino Queues was such a pain to write is the persistence format. Right now, I have a very easy solution for persistent data, Esent, so I don't think it would be much of a challenge. About using the doc db for this, you _could_, I just see no reason that you would _want_ to do that. http://ayende.com/3912/designing-a-document-database-what-next#comment13http://ayende.com/3912/designing-a-document-database-what-next#comment13Tue, 17 Mar 2009 16:35:06 GMTisn`t it easier to just build a installer for CouchDB on windows to make it easier to install? i understand the challenge and satisfaction of building something like that(building a database myself,but for really different needs) but there is already a really good product like CouchDB written in a really good language for the task(except for the IO part,if i am not wrong) so why reinvent the wheel. after saying that,for educational purposes of teaching how to build something like that to people who aren`t familiar with functional programming,that maybe a good reason. http://ayende.com/3912/designing-a-document-database-what-next#comment12http://ayende.com/3912/designing-a-document-database-what-next#comment12Tue, 17 Mar 2009 13:33:33 GMTCompanies possibly interested in this project: Microsoft I don't see any other who may consider it. Worst if it is a windows only solution. http://ayende.com/3912/designing-a-document-database-what-next#comment11http://ayende.com/3912/designing-a-document-database-what-next#comment11Tue, 17 Mar 2009 12:34:38 GMTHi, What are your thoughts on using sharepoint to be the document repository and using its api for some of the tasks? Regards http://ayende.com/3912/designing-a-document-database-what-next#comment10http://ayende.com/3912/designing-a-document-database-what-next#comment10Tue, 17 Mar 2009 12:07:23 GMTHmm, I might be really off track here, but isn't it all a re-implementation of Couch DB? I mean, yeah, I do get that couch DB is not a feasible option for the Windows environment, fair enough, but why re-designing it? Would love to hear what are the functional differences between this and the Couch DB, especially the reasoning behind it. I think this can provide some insights into what else Couch DB is lacking, or what kind of scenarios this new project is more suitable for. Cheers, F http://ayende.com/3912/designing-a-document-database-what-next#comment9http://ayende.com/3912/designing-a-document-database-what-next#comment9Tue, 17 Mar 2009 11:30:52 GMTAyende It's not related directly to DocDB. I know of a project where an API was written to use SQL Servers Queues much in the same vein as MSMQ, but only to 'facilitate store and forward' at the point of publishing or sending a message. Transport in this scenario was handled by WCF and the dequeing of messages and their transport over the wire was wrapped in a transaction. Do you see any value in extending that idea to a docDB? Do documents map nicely enough to messages and with the transactional support, is this lite weight enough for it to be xcopy portable and a real alternative where MSMQ (or the like) is not going to be acceptable. So if you have a durable storage with support for transactions (like the doc DB under discussion), could it fill the gap and help make something like Rhino.Queues durable? http://ayende.com/3912/designing-a-document-database-what-next#comment8http://ayende.com/3912/designing-a-document-database-what-next#comment8Tue, 17 Mar 2009 11:30:40 GMT>> Couch DB is not supported on Windows This reason is good enough for me. Please don't abandon your project :) http://ayende.com/3912/designing-a-document-database-what-next#comment7http://ayende.com/3912/designing-a-document-database-what-next#comment7Tue, 17 Mar 2009 10:45:19 GMTErik, ORM == Object Relational Mapping If there are no relations, there is no ORM. There is absolutely no challenge in building a layer on top of the doc db. Querying a doc db is not really feasible, that is why we have views. http://ayende.com/3912/designing-a-document-database-what-next#comment6http://ayende.com/3912/designing-a-document-database-what-next#comment6Tue, 17 Mar 2009 10:06:45 GMTRafal, a) Couch DB is not supported on Windows. There is some lengthy process you can go through to get it working, but it is not supported there, and there are several things that it does that make it not work nicely. b) Couch DB is running on Erlang. In most environments, it is... hard to get a new platform in. .Net is already acceptable for most, and that make is much easier to adopt it. http://ayende.com/3912/designing-a-document-database-what-next#comment5http://ayende.com/3912/designing-a-document-database-what-next#comment5Tue, 17 Mar 2009 10:04:14 GMTSimon, I am not sure that I understand what you mean. I don't see how queuing is related to Doc DB. http://ayende.com/3912/designing-a-document-database-what-next#comment4http://ayende.com/3912/designing-a-document-database-what-next#comment4Tue, 17 Mar 2009 10:00:59 GMTI have to agree with Rafal, instead of building "CouchDB.Net" maybe we could build a new "Hibernate" or Linq layer for existing schema-less databases? Of course it depends on what we intend to do with our document DB... http://ayende.com/3912/designing-a-document-database-what-next#comment3http://ayende.com/3912/designing-a-document-database-what-next#comment3Tue, 17 Mar 2009 09:26:30 GMTAyende, there is one question that wasn't asked before: why did you want to build Couch DB at all, since the original is already built and is free? This elliminates the need to pay for a document database. In your posts I didn't see any feature comparison of couch db and your project, it would probably help to state something like 'my database will have better implementation of X and Y and will provide extra features like Z and ...' How to make money on such project? Incorporate it into some business application, like document management system. BTW, I spent half of last night updating application on customer's servers. Needed to change table structure, unfortunately the table has millions of records and the update took a hour and half. My service window was exactly 60 minutes, so I did not make it on time and had to call for extra minutes making customer very anxious. And it was just adding several fields..What would happen if the operation failed and had to be repeated - probably a catastrophe.. and next updates will be only worse. I regret the application isn't built on a schema-less database. http://ayende.com/3912/designing-a-document-database-what-next#comment2http://ayende.com/3912/designing-a-document-database-what-next#comment2Tue, 17 Mar 2009 07:19:44 GMTAyende What about extending this into Queuing? What would be involved in turning the idea on it's head a little and using a document to describe a message? What about the API that would be required, would you simply make the messaging work within the confines of the REST API that you proposed? How about making it work in a Sandboxed technology such as Silverlight. Silverlight currently makes the Store and Forward pattern very difficult. I am curious. http://ayende.com/3912/designing-a-document-database-what-next#comment1http://ayende.com/3912/designing-a-document-database-what-next#comment1Tue, 17 Mar 2009 07:05:03 GMT