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 2006-02-11 18:35
on 2006-02-11 18:46
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 2006-02-11 19:06
... 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.
on 2006-02-11 20:25
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)
on 2006-02-11 20:29
ok, understood. thx On 11 Feb 2006 18:25:05 -0000, Mikkel B.
on 2006-02-11 21:57
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.
on 2006-02-11 22:01
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)
on 2006-02-12 01:10
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 B.
on 2006-02-12 10:39
On 11 Feb 2006 20:00:55 -0000, Mikkel B. <email@example.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
on 2006-02-12 11:09
DHH has written about this. =) http://www.loudthinking.com/arc/000516.html - Rabbit ---
on 2006-02-12 14:40
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)
on 2006-02-12 15:58
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.
on 2006-02-12 16:14
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 2006-02-12 16:27
On Sun, Feb 12, 2006 at 09:39:35AM +0100, Mariano K. wrote: > On 11 Feb 2006 20:00:55 -0000, Mikkel B. > <firstname.lastname@example.org> 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
on 2006-02-12 17:12
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 J.
on 2006-02-12 23:29
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/
on 2007-02-07 12:14
6d55aa5692683c7bfd383a1914936789 <a href="http://cumonboots.imikkladanno.info/2005-08-29.htm... 2005-08-29.html </a> http://winx.pratereoutdra.info/2005-07-15.html <a href="http://dis4kids.perekatinetuzaba.info/2005-07-11.h... 2005-07-11.html </a> <a href="http://jeanharlowgallery.manotiifrast.info/2005-09... 2005-09-24.html </a> http://cumonboots.imikkladanno.info/2005-09-25.html <a href="http://goemerchent.lopatajovtara.info/2005-08-21.h... 2005-08-21.html </a> <a href="http://rincondedontomas.perekatinetuzaba.info/2005... 2005-09-01.html </a> http://egner-umwelttechnologie.zhabartufa.info/200... <a href="http://beavon-family.zhabartufa.info/2005-08-03.ht... 2005-08-03.html </a> <a href="http://fasod.uzxocantailim.info/2005-10-01.html"> 2005-10-01.html </a> http://patersonrealestatevideos.qupitaratersadno.i... <a href="http://catoregon.perekatinetuzaba.info/2005-10-10.... 2005-10-10.html </a> <a href="http://massergycommunications.wertzaobtara.info/20... 2005-09-10.html </a> http://xn--consoles-vido-mhb.qupitaratersadno.info... <a href="http://multipurposecard.uzxocantailim.info/2005-09... 2005-09-25.html </a> <a href="http://implant-dentist-new-jersey.imikkladanno.inf... 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 </a> http://sitele.perekatinetuzaba.info/2005-07-17.html <a href="http://artadabsurdum.manotiifrast.info/2005-09-14.... 2005-09-14.html </a> <a href="http://tjhoover.trudnodostupna.info/2005-09-09.htm... 2005-09-09.html </a> http://deadvoltage.pratereoutdra.info/2005-10-01.html <a href="http://legolink.perekatinetuzaba.info/2005-09-27.h... 2005-09-27.html </a> 62391812410bcc1759701cfaa7e33dba