but for some reason that doesn't quite feel like a good solution.
that, overall, makes sense, and is very little code..combine it with a
before callback or method_missing?
what about it seems like a poor solution?
I come back to asking, will all wheel classes have the same attributes
and
Pete Hodgson wrote:
Hi All,
I have an interesting Active Record problem and I'm not quite sure what
the cleanest solution is. The legacy database that I am integrating with
has a strange wrinkle in its schema where one logical table has been
'partitioned' into several physical tables. Each
Gabriel Saravia wrote:
but for some reason that doesn't quite feel like a good solution.
that, overall, makes sense, and is very little code..combine it with a
before callback or method_missing?
what about it seems like a poor solution?
I come back to asking, will all wheel classes
Marnen Laibow-Koser wrote:
Why not create a wheels view which combines the data from all the
wheels_for_* tables, then tie your Wheel model to that?
Best,
--
Marnen Laibow-Koser
http://www.marnen.org
mar...@marnen.org
I think that would have some performance issues. If there were 20
Also, that view would not be updatable (updateable?)
Not sure if that is a requirement but something to be aware of.
On May 13, 11:46 am, Pete Hodgson rails-mailing-l...@andreas-s.net
wrote:
Marnen Laibow-Koser wrote:
Why not create a wheels view which combines the data from all the
Secondly, does anyone have any pointers on how I can make this work in
Active Record in a nice clean way.
In a domain i'm workin in, this type of thing also came up, and I chose
to split it in a somewhat similar way using abstract classes. Create an
abstract class, Wheels, put all common
Gabriel Saravia wrote:
Wheel ActiveRecord::Base
self.abstract_class = true
CarToWheelsClassHash = {:ford = FordWheel}
def self.abstract_find(car_brand, *normalfindargs)
CarToWheelsClassHash[car_brand].constantize.find(*normalfindargs)
end
[other code common to all
Gabriel Saravia wrote:
The names of the various Wheel tables are not known at design
time.
well..if this is the case, i don't see how you're really going to keep
from some form of dynamic creation/metaprogramming/code generation and
also keep the design clean...
I guess the best I
8 matches
Mail list logo
