I''m running into a bit of a ideological and functional problem with
ActiveRecord and would like to find out if some of these concerns are
valid. Hopefully someone here already knows the answer...
The concerns are that ActiveRecord has a lot of activity involving data
validation (validates_uniqueness_of, validates_associated) and model
definition (belongs_to, has_many, has_one). This falls into three basic
areas of data management that might be better handled elsewhere. At
least that''s my olde school thinking.
model definition: belongs_to, has_many, has_one
These are all concepts that have been previously handled by standard SQL
concepts such as:
belongs_to:
This is addressed by the SQL
execute ''alter table contacts add constraint fk_contacts_users
foreign key (user_id) references users(id)
on delete cascade on update cascade''
has_many:
This is a data model that is not addressed by SQL directly
but is included in the SQL for belongs_to
has_one:
execute ''create unique index idx_contacts (username)
The common concern that I have for each of these is that the
ActiveRecord model may not always guarantee correct behaviors of the
data.
As an example: I have an application which requires that each user have
a unique name for login. If I have a database table [id, username] and
a ActiveRecord model which validates the uniqueness of the username.
What happens to the application when two people enter in the same
username (for INSERT) concurrently?
Is there something about the ActiveRecord which can manage the
Concurrency effectively enough that the underlying database does not
require an UNIQUE index on username?
My past experience with data systems would tell me that the answer is to
enforce a UNIQUE index on the username field and then validate
uniqueness of the data insert by handling the resulting database error
that is going to be thrown.
Additionally, (and this is my lack of understanding of ActiveRecord) I
am assuming that this validation is going to run a SQL statement to see
how many records match that name, and returning none, will insert the
record. That''s two queries instead of one plus error handling. Plus
it
doesn''t guarantee the data integrity that is required of the
application.
Similarly, any specific constraints on what kind of data is permitted
(price > 0) is something that can also be added as a constraint to the
database field. But some DBA''s and others would argue against this
since it''s not a data integrity requirement but a business requirement.
Perhaps it would be more agreeable to state the constraint as price >=
0 since we''re pretty sure we don''t want to sell at negative
values.
This last example is something that may not be as much of a hard and
fast rule as the previous requirements about data linking from table to
table or perhaps other requirements like a field cannot be null in the
database and the ActiveRecord validates that the field matches a set of
values.
There''s arguably two layers of data integrity: The rules that make the
business of running the web site make sense (price >=0) and the rules
that keep things from completely falling apart (unique username).
One partition is to consider the Model to contain everything that can be
compared to values in the model code or the data provided (in memory)
for that specific event. This would ensure the price >=0 or price > 0
or that a zip code is sane (5 digits US, 6 chars CA). And to handle the
errors returned from the database when the data integration rules are
violated (referential integrity, unique key violations...) rather than
trying to second guess the database.
This is where my thinking it as.
I''m trying to resolve what my options are in developing an application
that is going to provide both a Rails-ish approach yet still keep the
data sane.
Hints?
