Thanks Matt, Yea, as I mentioned, tags are probably a bad example. It certainly involves a bit of unlearning. For anyone else interested, I'll be at Jelly tomorrow working more on this. Drop by if you're interested.
Peter On Thu, May 21, 2009 at 9:32 PM, Matt Aimonetti <[email protected]> wrote: >> 1) When should CastedModel be used instead of ExtendedDocument? In >> some of the examples I see you are saving a CastedModel as a field >> inside a document. Other times you are saving an ExtendedDocument >> inside a document. But it appears to me that the end result is the >> same in the database. Can (or should) a CastedModel also be saved as a >> top level document, and if not, why not just use ExtendedDocument for >> everything to allow that flexibility? > > > ExtendedDocuments == real DB documents > CastedModel == Hash inside a document > > A Casted Model doesn't have a save method or a create method, it also > doesn't have an id, revision. You can access the parent of a CastedModel if > you want to save it. > > You might want to cast an ExtendedDocument in the off chance that you have a > model that's being stored as a document as a well as an attribute, I would > recommend against doing that as you might encounter some weird behaviors. > >> 2) Collections... When implementing something like tags for instance, >> do you think it's better design to add each new tag to the document as >> a separate property field, or as a cast_as collection? (BTW, tags may >> be a bad example because they could simply be strings, but assuming I >> want them to be typed.) > > I usually use cast_as collections. But I usually cast to CastedModels, not > ExtendedDocuments. > >> 3) Sticking with the tag example above, if I am also creating top >> level documents for each tag in my database, do you think it's good >> practice to stay denormalized by also storing the whole tag in the >> tagged document? So... > > > In the case of tags, I would strongly suggest to store them as an array of > strings and use views to get the data you want. > You can for instance create a view that will emit each tag for a document as > well as 1. This way you can easily create a cloud map using a reduce > function. (I believe you will find some examples on the wiki). > I totally don't see the need to store tags as their own documents. In real > life, what would you do? Write down a sheet per tag and then add post-its > with the ids of sheet for each of your items? Probably not ;) > >> 4) And finally, what are your thoughts on using the _attachment field >> for storing something like profile photos... or is it still better to >> use a solution like Paperclip + AWS? It all seems very nice from >> Futon, but do document based databases really make this the better way >> to go. What about CDNs? > > Be careful with attachments, you can deal with it using 2 different ways. > Inline your attachments in the document (bad idea), or make an extra call to > save the attachment like an email attachment. I personally find it very > interesting and attractive. One small issue I'm working on is how to stream > attachment if your db isn't available from the web. Regarding CDNs, well.. > the good news is that you can now create your own really easily, by setting > up a server in asia and one in europe and replicate your dbs ;) > > Not having to deal with Paperclip/attachment_fu and s3 is just awesome. > (note that you could use ec2 instances just to serve assets.) > > - Matt > > > On Thu, May 21, 2009 at 3:39 PM, Peter <[email protected]> wrote: >> >> Matt, >> >> Thanks again for sharing these examples. After looking them over (and >> reading the specs) I have a few new questions. I hope others may find >> this useful as well: >> >> >> 1) When should CastedModel be used instead of ExtendedDocument? In >> some of the examples I see you are saving a CastedModel as a field >> inside a document. Other times you are saving an ExtendedDocument >> inside a document. But it appears to me that the end result is the >> same in the database. Can (or should) a CastedModel also be saved as a >> top level document, and if not, why not just use ExtendedDocument for >> everything to allow that flexibility? >> >> >> 2) Collections... When implementing something like tags for instance, >> do you think it's better design to add each new tag to the document as >> a separate property field, or as a cast_as collection? (BTW, tags may >> be a bad example because they could simply be strings, but assuming I >> want them to be typed.) >> >> property :tags, :cast_as => ["Tag"] >> >> vs. >> >> tag_one: { >> "name": "wild", >> "couchrest-type": "Tag" >> } >> tag_two: { >> "name": "mild", >> "couchrest-type": "Tag" >> } >> >> >> >> 3) Sticking with the tag example above, if I am also creating top >> level documents for each tag in my database, do you think it's good >> practice to stay denormalized by also storing the whole tag in the >> tagged document? So... >> >> # normalized >> property :tags, :cast_as => ["String"] # An array of Tag ids >> >> vs. >> >> # denormalized (assuming this stores the whole tag) >> property :tags, :cast_as => ["Tag"] >> >> Or even... >> >> # normalized >> tag_one_id: "0ec292a425aa3225994832a086c95d7a" >> tag_two_id: "e76bb7825fca3f678b69d88c2a831edc" >> >> vs. >> >> # denormalized >> tag_one: { >> "name": "wild", >> "_rev": "1-3363921651", >> "_id": "0ec292a425aa3225994832a086c95d7a", >> "couchrest-type": "Tag" >> } >> tag_two: { >> "name": "mild", >> "_rev": "1-1029362251", >> "_id": "e76bb7825fca3f678b69d88c2a831edc", >> "couchrest-type": "Tag" >> } >> >> >> >> 4) And finally, what are your thoughts on using the _attachment field >> for storing something like profile photos... or is it still better to >> use a solution like Paperclip + AWS? It all seems very nice from >> Futon, but do document based databases really make this the better way >> to go. What about CDNs? >> >> >> Thanks again, >> Peter >> >> >> >> On May 15, 1:02 am, Matt Aimonetti <[email protected]> wrote: >> > After so many people got excited about CouchDB, I put quick example >> > together: >> > >> > http://gist.github.com/112109 >> > >> > I'll try to write a blog post in the next few days. >> > >> > - Matt >> > > > > > -- Peter Gumeson [email protected] --~--~---------~--~----~------------~-------~--~----~ SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby -~----------~----~----~----~------~----~------~--~---
