Hi,
when I define a db column to be non-nullable or of length 20 or as
numeric, I would expect rails to validate that, but that doesn’t seem
to be the case.
Any idea why that is? The metadata is accessible, at least in the
mysql case.
I am using rails 1.0 with mysql 5.
Cheers,
Mariano
On Saturday, February 11, 2006, at 5:35 PM, Mariano K. wrote:
Hi,
when I define a db column to be non-nullable or of length 20 or as
numeric, I would expect rails to validate that, but that doesn’t seem
to be the case.Any idea why that is? The metadata is accessible, at least in the
mysql case.I am using rails 1.0 with mysql 5.
Rails doesnt support db metadata…only columntypes
This is not a bug or missing feature…its intentional…
Mikkel B.
www.strongside.dk - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk - Buy Old Stuff!(DK)
On Saturday, February 11, 2006, at 6:06 PM, Mariano K. wrote:
… and column names and table names …
What do you mean with intentional? What is the intension? The DRY
principle is violated when I duplicate information, isn’t it?
Yes…configure as little as possible in the database…Its your models
that holds the constraints and validations…not the db
Mikkel B.
www.strongside.dk - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk - Buy Old Stuff!(DK)
… and column names and table names …
What do you mean with intentional? What is the intension? The DRY
principle is violated when I duplicate information, isn’t it?
Cheers,
Mariano
On 11 Feb 2006 16:46:49 -0000, Mikkel B.
ok, understood.
thx
On 11 Feb 2006 18:25:05 -0000, Mikkel B.
This is only plausible in an environment in which your Rails app (or
other Ruby code using your model) is connecting to the database. In a
distributed, enterprise environment where the database could be
touched by multiple apps, this is not as feasible… unless you want
to export your models w/ some sort of ActionWebService and force all
other apps that wish to update the database to use that service.
Putting constraints and limits into the DB schema is NOT a bad thing.
-Will
On 11 Feb 2006 18:25:05 -0000, Mikkel B.
In my opinion, the key reason is that Rails has a “sweetspot” set of
applications that it’s trying to fit as well as possible, and other
apps are to some extent intentionally supported less well.
The sweetspot seems to be:
Although it may not sound like it, I think the Rails approach is a
very good one. It’s a very close fit for a large percentage of Web
applications at the moment, and it greatly improves the turnaround
time for these apps. As long as you stick to the sweet spot, Rails
development is massively more productive and enjoyable than with just
about any other framework out there (except for, possibly, the new
breed of Rails-like tools such as Django).
On the other hand, Rails is not about to replace Java as THE
environment for enterprise development. Java, and particularly J2EE,
supports all that work that falls outside of Rails’ sweet spots (e.g.
linking to legacy databases), which is where Rails would tend to
struggle. Sure you could do this work with Rails, but it would be
much less enjoyable and your productivity would suffer to the point
where Rails would not have a strong time-to-market case compared to
e.g. Java.
Regards
Dave M.
On 11 Feb 2006 20:00:55 -0000, Mikkel B.
On 11 Feb 2006 20:00:55 -0000, Mikkel B.
[email protected] wrote:
In agree to some point…Im im frankly surprised that the OP accepted my
reply as a fact…
OP = other person? Funny.
Well, I didn’t take it as a fact. I just stopped arguing because I
understood your point and you already confirmed that I haven’t
overseen the feature, but that it is indeed not available.
It doesn’t make too much sense to me though, but as everything in
rails is about sweet spots and being opinionated it was a good enough
answer for me to understand where you were coming from.
From my point of view there are two basic approaches.
a) Use the meta data from the database and don’t repeat that in your
code. So the code is dependant on the db or
b) Define the meta data in the code and derive the database from it.
Frankly, I am surprised that rails didn’t go for b). Rails is all
about expecting the problem and the environment to be appropriate. So
why stop at the db and go for this in between approach?
DBs can holds some simple meta data, XML is a bit better, but the real
power to describe a meta model is in code. Left aside that this can
distract you from building declarative meta data you can do everything
in code that you could do with the db.
And this has now downsides if your are in the rails sweet spot.
So why did the buck stop at the db? Why not define the attributes in
the model? Wouldn’t that be more pragmatic, more dry?
Cheers,
Mariano
On Saturday, February 11, 2006, at 2:57 PM, Will B. wrote:
In agree to some point…Im im frankly surprised that the OP accepted my
reply as a fact…
As you and I both know, app design is not black and white…
Other apps could use the database etc…
Nevertheless Im my pov, all new apps should be designed with constraints
in the object model and as the db just acting as a simple storage
container…
But there really isnt any REAL answer to this…
Mikkel B.
www.strongside.dk - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk - Buy Old Stuff!(DK)
Mikkel,
no, not even using OP instead of my actual name offended me 
Thanks for sharing your insights.
Cheers,
Mariano
On 12 Feb 2006 12:40:06 -0000, Mikkel B.
OP original poster…
Well, I didn’t take it as a fact. I just stopped arguing because I
understood your point and you already confirmed that I haven’t
overseen the feature, but that it is indeed not available.
fact was really the word iwas looking for…sorry if i offended you…
Mikkel B.
www.strongside.dk - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk - Buy Old Stuff!(DK)
Rabbit,
thank you for pointing out the link. I read it and the referenced
articles.
That doesn’t change what I said though. Actually it underlines my
point.
I wasn’t talking about putting more constraints into the database.
Why not go the other way around and derive the database from the
domain model defined in ruby? Wouldn’t it makes sense to define the
types of the persistent attributes and generate the DDL from there.
IMHO this would be cleaner. Well, it is always cleaner to have
one-way dependencies. Currently the dependencies are two-way, aren’t
they?
Names of tables and columns as well as the column types are read from
the database, unless overriden, but the attribute constraints and
interrelationsships are defined in the model (and probably also
redundantly in the db model too).
And if you look at migrations it gets somewhat into the direction I
am describing. There you define physical and db dependend stuff of the
database in the migration, like the tabletype (InnoDB vs. MyISAM) in
Ruby, not in the model though.
Does this make sense?
But yes, in my original question I was asking why we don’t take more
stuff from the db metadata? This question was more pragmatic and came
from learing rails at the moment.
Cheers,
Mariano
On Sun, Feb 12, 2006 at 09:39:35AM +0100, Mariano K. wrote:
On 11 Feb 2006 20:00:55 -0000, Mikkel B.
[email protected] wrote:In agree to some point…Im im frankly surprised that the OP accepted my
reply as a fact…OP = other person? Funny.
OP usually means “Original Poster”.
–
- Adam
** Expert Technical Project and Business Management
**** System Performance Analysis and Architecture
****** [ http://www.everylastounce.com ]
[ Adam Fields (weblog) - - entertaining hundreds of millions of eyeball atoms every day ] … Blog
[ Adam Fields Resume ]… Experience
[ Adam Fields | Flickr ] … Photos
[ http://www.aquicki.com/wiki ]…Wiki
[ http://del.icio.us/fields ] … Links
getting attributes from the database is straightforward. Creating
validations & associations from constraints is not, because
constraints often have semantic meaning. It would be difficult to
define, and it would be brittle. As far as things like not null, etc.
I don’t see what the advantage would be to have rails creating magic
validation. You would still have to write code to handle the
failures. That would involve defining a method. The only difference
from the current situation would be the name of the method – it
would be like, failed_validation_of_xxx instead of validates_xxxx.
if the association were magic, not in the entity code, it would make
the app extremely difficult to read.
If all you want is the associations autogenerated into the entity
code, you could roll that into the generator script. For a very large
model with straightforward semantics done all at once, it might save
you a little bit of time. For incremental development, it would
probably cost you time. The act of manually typing in the
associations helps you check your mental model of your model and make
sure you’ve got it right.
Although the sweet spot for Rails development is from-scratch web
apps with db designed for the web app, deriving the db from the model
would restrict it to that arena, which would not be a good thing. And
there’s no productivity advantage: somewhere I have to define a set
of tables & attributes, there’s no productivity advantage to it being
in the ruby code as opposed to sql. The advantage of having it in sql
is that I can use pre-existing databases, I can tailor the
definitions to my specific database, etc. If the db was derived from
the model, I would frequently end up in the situation of having to
coerce an abstraction layer to carry a semantic meaning that I need
for a particular situation that the framework developers didn’t (and
neither could have nor should have) anticipate(d).
All things considered, the way it is is probably the best way that it
should be. It is a reflection of the fact that the framework
developers had a lot of experience developing web apps, and thought
about it deeply & pragmatically. It has compromises. They are the
right – or at least very good – compromises for the target.
Michael J.
Mariano,
As a side note here, you might want to take a look at Nitro+Og. Nitro is
a web framework
with a lot of similarities to ActionPack and Og is an ORM that’s
Object/Code-oriented
rather than DB-oriented. In other words, you tell Og about your model
objects and it deals
with the database for you.
The downside is that the site and documentation are pretty spotty and
there is way less
community energy around it than there is around rails. It’s too bad
really… I wish some
of these sharp Ruby guys that are driving rails would put some time into
Nitro+Og.
Although, actually, Nitro is similar enough to ActionPack, that it would
probably be cool
enough if someone just figured out how to use Og in a rails app… maybe
have a generator
option to create Og persistence instead of ActiveRecord.
Anyway, just thought I’d point that out if the db-oriented approach of
ActiveRecord is
chafing you.
b
6d55aa5692683c7bfd383a1914936789
2005-08-29.html http://winx.pratereoutdra.info/2005-07-15.html
2005-07-11.html
2005-09-24.html http://cumonboots.imikkladanno.info/2005-09-25.html
2005-08-21.html
2005-09-01.html
http://egner-umwelttechnologie.zhabartufa.info/2005-08-09.html
2005-08-03.html
2005-10-01.html
http://patersonrealestatevideos.qupitaratersadno.info/2005-07-28.html
2005-10-10.html
2005-09-10.html
http://consoles-vidéo.qupitaratersadno.info/2005-09-20.html
2005-09-25.html
2005-10-03.html
http://planetflirt.lopatajovtara.info/2005-09-05.html 2005-09-24.html
2005-08-09.html http://sitele.perekatinetuzaba.info/2005-07-17.html
2005-09-14.html
2005-09-09.html
http://deadvoltage.pratereoutdra.info/2005-10-01.html
2005-09-27.html
62391812410bcc1759701cfaa7e33dba
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs