Rails - Feb 2006 - Why does''nt rails pick up more metadata from a mysql schema?

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 Kamp
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 Bruun

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)




-- 
Posted with http://DevLists.com.  Sign up and save your time!

... 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 Bruun
<devlists-rubyonrails@devlists.com> wrote:
>
> On Saturday, February 11, 2006, at 5:35 PM, Mariano Kamp 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 Bruun
>
> www.strongside.dk    - Football Portal(DK)
> nflfeed.helenius.org - Football News(DK)
> ting.minline.dk      - Buy Old Stuff!(DK)
>
>
>
>
> --
> Posted with http://DevLists.com.  Sign up and save your time!
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Saturday, February 11, 2006, at 6:06 PM, Mariano Kamp
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 Bruun

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)




-- 
Posted with http://DevLists.com.  Sign up and save your time!

ok, understood.

thx

On 11 Feb 2006 18:25:05 -0000, Mikkel Bruun
<devlists-rubyonrails@devlists.com> wrote:
>
> On Saturday, February 11, 2006, at 6:06 PM, Mariano Kamp 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 Bruun
>
> www.strongside.dk    - Football Portal(DK)
> nflfeed.helenius.org - Football News(DK)
> ting.minline.dk      - Buy Old Stuff!(DK)
>
>
>
>
> --
> Posted with http://DevLists.com.  Sign up and save your time!
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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 Bruun
<devlists-rubyonrails@devlists.com> wrote:
>
> On Saturday, February 11, 2006, at 6:06 PM, Mariano Kamp 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 Bruun
>
> www.strongside.dk    - Football Portal(DK)
> nflfeed.helenius.org - Football News(DK)
> ting.minline.dk      - Buy Old Stuff!(DK)
>
>
>
>
> --
> Posted with http://DevLists.com.  Sign up and save your time!
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Saturday, February 11, 2006, at 2:57 PM, Will Briggs
wrote:
>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
>
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 Bruun

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)




-- 
Posted with http://DevLists.com.  Sign up and save your time!

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:
- database can be designed and implemented to fit Rails'' specific
defaults (e.g. "id" fields as primary keys, foreign key fields named
"table_id", "join" tables named "table1_table2")
- the database is only used for the Rails application, or, anything
else connecting to it has to do so through e.g. Web services
- rapid agile deployment is the key deliverable (ahead of, say, formal
requirements documentation, formal design documentation, etc.).  "Get
it released early and update often" is the Rails approach
- application accesses a single database
- the testing is unit-test centric, with a lot of focus being placed
on unit testing.  Rails stresses/supports this a lot more than most
other development frameworks
- the Rails model is a developer-centric model, with e.g. DBAs
marginalised at least to some extent.  With a Rails app, DBAs would
tend to given a reasonably fluid database and schema to support and
expected to "just do it", which is a long way from the approach used 
over many years for e.g. enterprise database apps
- apps involving fancy Ajax stuff

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 Bruun
<devlists-rubyonrails@devlists.com> wrote:
>
> On Saturday, February 11, 2006, at 2:57 PM, Will Briggs wrote:
> >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
> >
>
> 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 Bruun
>
> www.strongside.dk    - Football Portal(DK)
> nflfeed.helenius.org - Football News(DK)
> ting.minline.dk      - Buy Old Stuff!(DK)
>
>
>
>
> --
> Posted with http://DevLists.com.  Sign up and save your time!
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 11 Feb 2006 20:00:55 -0000, Mikkel Bruun
<devlists-rubyonrails@devlists.com> 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

DHH has written about this. =)

http://www.loudthinking.com/arc/000516.html

- Rabbit

---

On 2/12/06, Mariano Kamp <mariano.kamp@gmail.com>
wrote:
> On 11 Feb 2006 20:00:55 -0000, Mikkel Bruun
> <devlists-rubyonrails@devlists.com> 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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 Bruun

www.strongside.dk    - Football Portal(DK)
nflfeed.helenius.org - Football News(DK)
ting.minline.dk      - Buy Old Stuff!(DK)




-- 
Posted with http://DevLists.com.  Sign up and save your time!

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 Bruun
<devlists-rubyonrails@devlists.com> wrote:
> 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 Bruun
>
> www.strongside.dk    - Football Portal(DK)
> nflfeed.helenius.org - Football News(DK)
> ting.minline.dk      - Buy Old Stuff!(DK)
>
>
>
>
> --
> Posted with http://DevLists.com.  Sign up and save your time!
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

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 2/12/06, Rabbit <rabbitblue@gmail.com> wrote:
> DHH has written about this. =)
>
> http://www.loudthinking.com/arc/000516.html
>
> - Rabbit
>
> ---
>
> On 2/12/06, Mariano Kamp <mariano.kamp@gmail.com> wrote:
> > On 11 Feb 2006 20:00:55 -0000, Mikkel Bruun
> > <devlists-rubyonrails@devlists.com> 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
> > _______________________________________________
> > Rails mailing list
> > Rails@lists.rubyonrails.org
> > http://lists.rubyonrails.org/mailman/listinfo/rails
> >
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On Sun, Feb 12, 2006 at 09:39:35AM +0100, Mariano Kamp
wrote:
> On 11 Feb 2006 20:00:55 -0000, Mikkel Bruun
> <devlists-rubyonrails@devlists.com> 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 ]

[ http://www.aquick.org/blog ] ............ Blog
[ http://www.adamfields.com/resume.html ].. Experience
[ http://www.flickr.com/photos/fields ] ... Photos
[ http://www.aquicki.com/wiki ].............Wiki
[ http://del.icio.us/fields ] ............. Links

1. Re: deriving the model from the database:

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.

2. Re: deriving the database from the model.

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 Johnston

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

PS: http://nitrohq.com/

Mariano Kamp wrote:
> On 11 Feb 2006 20:00:55 -0000, Mikkel Bruun
> <devlists-rubyonrails@devlists.com> 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
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

6d55aa5692683c7bfd383a1914936789
<a href="http://cumonboots.imikkladanno.info/2005-08-29.html"> 
2005-08-29.html </a> http://winx.pratereoutdra.info/2005-07-15.html <a 
href="http://dis4kids.perekatinetuzaba.info/2005-07-11.html"> 
2005-07-11.html </a>
<a
href="http://jeanharlowgallery.manotiifrast.info/2005-09-24.html">
2005-09-24.html </a> http://cumonboots.imikkladanno.info/2005-09-25.html 
<a href="http://goemerchent.lopatajovtara.info/2005-08-21.html">
2005-08-21.html </a>
<a
href="http://rincondedontomas.perekatinetuzaba.info/2005-09-01.html">
2005-09-01.html </a> 
http://egner-umwelttechnologie.zhabartufa.info/2005-08-09.html <a 
href="http://beavon-family.zhabartufa.info/2005-08-03.html"> 
2005-08-03.html </a>
<a href="http://fasod.uzxocantailim.info/2005-10-01.html"> 
2005-10-01.html </a> 
http://patersonrealestatevideos.qupitaratersadno.info/2005-07-28.html <a 
href="http://catoregon.perekatinetuzaba.info/2005-10-10.html"> 
2005-10-10.html </a>
<a 
href="http://massergycommunications.wertzaobtara.info/2005-09-10.html">
2005-09-10.html </a> 
http://xn--consoles-vido-mhb.qupitaratersadno.info/2005-09-20.html <a 
href="http://multipurposecard.uzxocantailim.info/2005-09-25.html"> 
2005-09-25.html </a>
<a 
href="http://implant-dentist-new-jersey.imikkladanno.info/2005-10-03.html">
2005-10-03.html </a> 
http://planetflirt.lopatajovtara.info/2005-09-05.html <a 
href="http://ilawaid.imikkladanno.info/2005-09-24.html">
2005-09-24.html
</a>
<a 
href="http://industrialsystemsservices.imikkladanno.info/2005-08-09.html">
2005-08-09.html </a> http://sitele.perekatinetuzaba.info/2005-07-17.html 
<a
href="http://artadabsurdum.manotiifrast.info/2005-09-14.html">
2005-09-14.html </a>
<a href="http://tjhoover.trudnodostupna.info/2005-09-09.html"> 
2005-09-09.html </a> 
http://deadvoltage.pratereoutdra.info/2005-10-01.html <a 
href="http://legolink.perekatinetuzaba.info/2005-09-27.html"> 
2005-09-27.html </a>
62391812410bcc1759701cfaa7e33dba

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
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
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---