Re: Re: DRY for ActiveRecord w/PostgreSQL : defaults and validations

Alex Young
Mon, 19 Sep 2005 13:51:30 -0000

Lugovoi Nikolai wrote:
> Basically, there are two choices where to put business logic and how
> much of it will go to DB or app code (in any case, portions will be
> present in both)
But we should minimise the amount in one, and maximise it in the other...

> So, if one''s model is primarily an Object-Oriented one,
constraints are
> defined and handled by classes and methods, and if data model grounds
> mainly, say, on relational theory, constraints are defined and handled
> by RDBMS (yes, we don''t yet have one, only SQL DBMS ;-( ).
That''s what I''m saying, really.  Given that AR requires that
we put some
model definition in ruby, why not have the option to put it all there?
That way we can compensate for dodgy back-ends when we have to, without
endangering the data.

> My view of validations - keep software more fool-proof (but that''s
the
> primary goal of constraint) and more luser-friendly.
I find that the latter comes through clarity and consistency of expression.

> Clearer? Maybe, as for developer.
> More reliable? I doubt, unless such constraints are pushed from AR to
> DB.
That''s exactly what I''m proposing, although I can now see a
slight
hitch:  What should happen when there''s a constraint already defined on
the schema, and the AR model has a conflicting definition?  My instinct
says to fail hard and as early as possible under those circumstances.

> And, as for me, it''s rather  scary to develop serious apps against
poor
> DBMS, though even SQLite can be appropriate sometimes.
I couldn''t agree more.  I''d like to be able to develop on a
rock-solid
platform, but let the user be able to run a shoddy back-end if their
circumstances dictate it, and suffer as little as possible for it.

To take a very pertinent example, I''m currently developing a PHP site
that''s going to be using MySQL 4.0.17 because the host that my client
uses refuse to upgrade, and they refuse to go with a different host.  I
can''t use InnoDB tables throughout for a number of reasons, which means
transactions and foreign key constraints can''t be reliably supported by
the DB.  Does this mean they shouldn''t have them?  Hell no!

--
Alex