http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Sam, It just works, we have JS API available that you can use, and that is about it :-) http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment12http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment12Fri, 07 Jan 2011 09:59:01 GMTKhalid, I don't think so. They can be used for additional stuff, and I don't want to be too limiting http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment11http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment11Fri, 07 Jan 2011 09:58:38 GMTI noticed you talking about the concept of Raven Apps. Is this something that is still on the roadmap, and / or do you have any plans on releasing documentation / samples?? (I can't find any information on the RavenDB website at the moment) Cheers Sam http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment10http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment10Fri, 07 Jan 2011 00:18:03 GMTYou should put "attachments are mostly there as light weight option if you have really simplistic needs." In H1 tags on the documentation page. That sums it up perfectly in a short and sweet statement. http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment9http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment9Thu, 06 Jan 2011 17:45:55 GMTIt might be even more accurate to state that attachments are mostly there as light weight option if you have really simplistic needs. http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment8http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment8Thu, 06 Jan 2011 17:12:49 GMTKhalid, Yes, that is the case. http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment7http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment7Thu, 06 Jan 2011 17:11:50 GMTI completely agree with you that it can be safely and easily done externally to RavenDB. Also much easier for you since you (Oren) don't have to maintain it. Ultimately if I had to choose again, I would have created a concept of a File in my application and stored the binary files separately from RavenDB. I guess to clarify, RavenDB has attachments but your recommendation (mine as well) is not to build your application (.NET) storage on attachments. The attachments were to facilitate storage for web based apps (HTML5, Javascript) that ran on the client. Is that correct? http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment6http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment6Thu, 06 Jan 2011 17:06:20 GMTThanks for posting this; as one of the people who frequently requested this, your explanation of the situation from a technical perspective really helped to fill in the gaps. http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment5http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment5Thu, 06 Jan 2011 17:03:07 GMTKhalid, That sounds like something that can be done safely externally. And if it can be done safely & easily externally, I would much rather have it done that way. It reduces the amount of complexity that I have to deal with. http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment4http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment4Thu, 06 Jan 2011 16:52:43 GMTThe ability to index on the attachments? Yes What is the use case behind this? If I created a Wiki and allowed arbitrary attachments (google groups), I would probably end up creating a "File" model within my domain. I am stating that the notion of a file is probably standard enough that Raven could have a default File document, so you wouldn't have to add it to your domain every time you start an application that deals with files. If you want a different "File", create one that fits your domain better. standard file (IMO). File { Name, Created, Extension, Size, MD5Hash (maybe) } something like RavenFile ravenFile = Session.Attachments.Store(file); or RavenFile ravenFile = Session.Attachments.GetFileInfo(key); some examples. - For replication, we need to replicate attachments if we are replicating documents, because it is not good to tell users "yes, we support attachments, oh, but not for replication" I agree with you here it would be silly. What I meant, was I wouldn't store attachments in the database cause that functionality does exist. I wouldn't want it to replicate large files, but I know it will. So to avoid the replicating of large attachments, the only option is not to put them into the database. http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment3http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment3Thu, 06 Jan 2011 16:40:47 GMTKhalid, Attachments already have metadata, and I am not sure what having a document referencing an attachment would give you. The ability to index on the attachments? What is the use case behind this? For replication, we need to replicate attachments if we are replicating documents, because it is not good to tell users "yes, we support attachments, oh, but not for replication" http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment2http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment2Thu, 06 Jan 2011 16:15:21 GMTI agree with what you were saying. I don't know if my comment was unclear in any way, but I meant that if you do decide to have attachement in your DB instance it would be great if RavenDB would create a standard Attachment/File Document that coincided with that attachment, kind of like MetaData but more visible than metadata. At the very least it would be great to have a Raven index that could show you the attachments. You are right about replicating attachments, but why even do it to start with (from a developer's standpoint)? Depending on the size of your attachments, this could end up being costly to replicate. If you stored files in a system separate from the DB, it just becomes way more flexible for you when the time comes to refactor the storage aspect of your application. I think we have the same understanding, but I just learned it the hard way. :) http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment1http://ayende.com/4743/the-design-of-ravendb-s-attachments#comment1Thu, 06 Jan 2011 15:49:16 GMT