7

I have a Rails app with 600 models and that will soon grow to 800-1000. I'd like to segment the rails app so that only certain models get loaded and therefore act as a separate app, but all share the same base models. Is there a standard practice for doing this?

EDIT: I am on 2.3.8

EDIT 2:

The problem is that many models are similar, but different just enough that it warrants writing a new class, i.e. the logic required to put it all in one model would be horrendous. Some of the models could be moved out into rake tasks or the lib directory, but only about 30 or so. Some are abstract classes that act as parents of one arm of the model tree. However, most relate to database tables. I am thinking about at deploy time segmenting parts of the app into plugins via Engines so that one app can only handle one set of models (they are independent) but so that I can keep them all together in development and in one git repo for convenience. I"m going to go down this route unless someone else has a better idea, and I'll post back to let you know how it goes.

George Stocker
  • 57,289
  • 29
  • 176
  • 237
tesserakt
  • 3,231
  • 4
  • 27
  • 40
  • 11
    Good lord. That's a behemoth data model. Is this an inheritance tree that spun out of control, or what happened? I'm genuinely curious about this if you care to and are able to answer. – jdl Mar 07 '11 at 19:04
  • 1
    How long on average it takes to execute one request in development mode? – Greg Dan Mar 07 '11 at 19:26
  • I edited my question based on your responses. In dev, a request is just under a second. A little faster in prod. In production most things are cached in memcached or some other caching system. – tesserakt Mar 07 '11 at 21:31
  • Were you forced to create a big model by trying to save the objects' history? I ran into a similar problem a while ago while trying to do this. – Pablo Marambio Mar 07 '11 at 23:32
  • Ruby offers many ways to avoid such a design. 600-1000 classes does not seem manageable... – aceofspades Mar 07 '11 at 23:39
  • I cannot fathom what would make you say "currently have 600 models *and will soon grow to 800-1000*", and think that that's ok. I feel like you're looking at the problem from the wrong angle if you find it appropriate to estimate a growth of _200-300_ more database tables. As @fullware mentioned - that is simply not manageable. Your testing suite must be ridiculous. – nzifnab Mar 08 '11 at 07:39
  • Interested to hear what has happened with this project. Would you update us at all? – New Alexandria Dec 14 '13 at 17:25

1 Answers1

2

Dude, thats a pretty insane amount of models... anyways for handling complex logic and easily reuse them across other projects I would recommend to you the engines (from 2.3+ is part of Rails).

With that in place you can split your model in different modules (engines)

http://railscasts.com/episodes/149-rails-engines

Toño

Toño Silva Portell
  • 214
  • 3
  • 8
  • That's what I am currently considering, I"ll let everyone knows how it goes. I am wondering if this is what is slowing our rails app down? I'd like to get better response times out of it, they currently hover around a second. I'm also looking at moving to Ruby 1.9. – tesserakt Mar 08 '11 at 12:24
  • Instead of moving to 1.9 (lack of gems & plugins compatible) I would recommend you to try jRuby for faster responses times. I don't see any performance reduction on my app, using 6 engines to split my business login into modules. – Toño Silva Portell Mar 08 '11 at 19:04