<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">On 18 February 2015 at 12:00:20, Thomas Buckley-Houston (<a href="mailto:tom@tombh.co.uk">tom@tombh.co.uk</a>) wrote:</div> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>Thanks for the replies.

<br>

<br>I think Tim Diggins most gets what I'm on about, thanks :)

<br>

<br>My problem with poking around the console is that it's counter to the

<br>MVC philosophy of using the Model to describe your domain. Code *as*

<br>documentation and all that. In pretty much every other MVC framework

<br>and ORM I've come across, fields are described in the model. My

<br>question is really curiosity as to why this is? Is AR's fieldless

<br>models a known pattern? Or is there a historical reason in AR's

<br>development for it?

<br><br></div></div></span></blockquote><br><div>I think for a definitive answer you’d have to ask DHH, but it’s been the way it currently is since migrations were added (<a href="https://github.com/rails/rails/commit/eac7cf0b0608132673220d9045b8ff51dc0804e1">https://github.com/rails/rails/commit/eac7cf0b0608132673220d9045b8ff51dc0804e1</a>). Off the top of my head it seems easier to write the migration approach (at least the first implementation of it) than a model based declarative approach where you’d have to write something that diffs what is in the models versus the current state of the schema.</div><div><br></div><div>Fred</div></body></html>