On May 31, 10:13 pm, bill walton <[email protected]> wrote:
> Hi Brian,
>
> On Sun, 2009-05-31 at 16:34 -0700, Brian wrote:
> > ... I've run into a timing problem that
> > reveals a flaw in my design.
>
> Maybe.
>
> > It's most obvious when in the test environment: I need my model
> > classes declared before I can load fixtures, but the data from those
> > fixtures is needed before I can define my models because that's when I
> > generate all of my method names.
>
> Models do not factor into the picture WRT fixture loading. Fixture data
> does not 'pass thru' the model's validations.
>
> HTH,
> Bill
I would not have expected that models factored in either, until last
night. :)
First of all, the foxy fixtures for HABTM definitely depend on having
models in order to get the SQL query right. Which makes sense to me
-- the table I'm using to test doesn't have 'something' or
'something_id' columns so as far as it can tell I'm providing extra
data that doesn't fit into the table. It's not until models and
associations are loaded that it becomes apparent what this information
is for.
I also ran into trouble with 'fixture :foos' which ensures that :table
has a corresponding class, Foo. I don't recall whether this had to be
a subclass of ActiveRecord::Base (or even whether I checked this), but
obviously this is normally a model.
Your point is well taken though -- I could be using other means to
seed my test data, or even just bypassing some of the convenience of
the existing fixture infrastructure. But my testing problems were
really just the canary; I didn't explain it well in my initial post,
but there really are problems with my design. Specifically, I had
planned to treat the tables with security data just like any other
table in my app, with a corresponding model, and protected with my
security plugin. When I focus on this one table the problem is clear:
after my model is defined, I need to use it to access data which is a
prerequisite to defining models (including itself). I was too
concerned with the big picture to see the obvious paradox. Luckily I
caught this right away because I couldn't test it.
Mauricio makes a good observation about being tightly coupled to my
source of data. If I abstract this a bit I have more flexibility and
I can still load my data from a DB (just at an earlier time and
without pushing it into a model), or I can go with some sort of
configuration (probably writable class attributes for some
configuration class that can be set in an initializer). Getting my
data from the DB wasn't bad -- trying to smash it into the
ActiveRecord architecture was my mistake.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
