I’ve also fixed an error that arises when you specify and entire URL in CouchPotato::Config.database_name. In short, I’ve added CouchPotato::Config.database_server which will default to http://localhost:5984/ unless specified.

http://github.com/thefool808/couch_potato

Also, I’ve written up a real quick readme on what it took to get ruby1.9, couchdb-0.9.0, and your version of couch_potato up and running on Debian Lenny. If you would like to post it up, I can email it to you.

Now to actually write an application!

Already submitted a few small patches and one issue. I also figured out what you said above after finally getting moved over to Ruby 1.9 and getting a sample couchpotato app up and running.

BTW, I agree with your decision not to define associations. Currently I am stuck between liking certain aspects of your project, and certain aspects of CouchRest. I’ll add a few more issues on github so you can see what I’m talking about. However, I really like the overall design of CouchPotato.

“From what I can tell, defining a property as your own custom class simply stores an #{name}_id in your document that points to another document”

nope, it converts the object to json and stores it inline. at this point i have no plans for supporting any kind of relational things. if you want something like a has_one relation you can implement a method that then calls the appropriate view to load the related documents.

you can easily use multiple databases per rails/sinatra/merb app. just create multiple instances of CouchPotato::Database and then each talks to a different database.

right now there is no google group or something like that but i have that planned. in the meantime there is the wiki and the issue tracker on github for some sort of communication. the easiest way to contribute for now is to just fork the repo on github and start adding some code. you are very welcome to do so

Just wondering now what the best practice is for this capability. Set the property to null if you decide to promote it to it’s own document, or keep it around for easier access.

I have a few questions about the direction of the project, and couldn’t tell if the following things were possible with the current version.

From what I can tell, defining a property as your own custom class simply stores an #{name}_id in your document that points to another document, which I am guessing you would need to save separately. Do you envision something similar to the CastedModel in couchrest that is not so much like a relational thing.

Also, I am wondering if you envision supporting more than one database per rails project. Like if you want each model to have it’s own named database.

Finally, the code looks very clean and easy to jump into, do you have a mailing list or google group setup for the project in case one might want to start contributing.

Thanks,
Peter

yes this is ruby 1.9. plus i’m using a few other 1.9 things like Hash#map which returns an Array in 1.8 but a Hash in 1.9

define_method view_name do |view_parameters = {}|

Is this a ruby1.9 thing?

I plan on making this gem compatible with 1.8.