Anyone using DataMapper?

[cootcraig]

http://datamapper.org/

DataMapper is a Object Relational Mapper written in Ruby. The goal is
to create an ORM which is fast, thread-safe and feature rich.

I'm looking at using DataMapper as I explore Sinatra.

[ybakos]

Yes, and it's good shit. With Rails 3, it's nice to be able to swap in
this ORM. However, for a Rails project, I prefer AR due to the new
Arel API and the fact that all the Rails doco provides AR information.

There are nice API features in both DM and AR.

[James Higginbotham]

Yeah, DM is nice with Sinatra. Thanks for the links to the other Sinatra resources, as I've been looking for something that can take the place of Rails for most needs. 

--
You received this message because you are subscribed to the Google Groups "Not Just Ruby" group.
To post to this group, send email to not-ju...@googlegroups.com.
To unsubscribe from this group, send email to not-just-rub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/not-just-ruby?hl=en.

--
James Higginbotham
http://www.launchany.com - Helping startups break down the barriers to launch

http://www.bluejazzconsulting.com - Software consulting

http://www.volunteercentered.com - Volunteer recruiting and leadership

[James Higginbotham]

BTW, has anyone used any alternatives to ERB or HAML for UI markup? I'm experiencing render times in the hundreds of milliseconds range, which adds up when trying to get a high throughput website running about 100 requests/sec. I've seen erubus but haven't had the time to try it out yet. 

[ybakos]

James,
One thing that was cool about JSP template rendering during runtime is
that jsp's get compiled into class files. Big difference in rendering
performance when compared to runtime interpretation that Rails
exhibits.

I think you're on the right track w/ erubis.

But what's the content that you're trying to render so quickly? Is it
changing that dynamically? The Rails Way is to leverage caching,
leaving throughput in the hands of Apache/nginx.

[James Higginbotham]

(My apologies for changing the subject on this original thread)

The startup I've helped to launch has a considerable amount of customization and personalization, which prevents fragment caching at a level high enough to benefit performance in any meaningful way. For the pages that I could cache, it does speed up throughput considerably. I have also implemented some interesting methods of removing some of these personalizations by moving them to the client-side, but other than that I am limited on what I can cache. 

My other move is to try Ruby 1.9, but time doesn't allow for a thorough test of the codebase with it right now. 

--
You received this message because you are subscribed to the Google Groups "Not Just Ruby" group.
To post to this group, send email to not-ju...@googlegroups.com.
To unsubscribe from this group, send email to not-just-rub...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/not-just-ruby?hl=en.

[ybakos]

I don't think you'll see a big performance difference in page
rendering time between 1.8.x and 1.9. (But, I've never measured it).
Maybe a bigger difference between stock 1.8 and enterprise Ruby.

Regardless, I'll wager you would get the most performance gain w/
erubis.