Warning- I'm unreasonably picky about some things, and that's going to show through here.
I'm not sure what I think of the URL structure that I've seen with rails. A URL is a Uniform Resource Locater, and to me, that means a file on a webserver. Somehow, having a URL that doesn't point to a file on a server seems wrong to me. It obviously works, and I'm not saying that this is A Thing That Should Not Be. But it bugs me.
This next part comes from an example in the book, which may have been written to be simple, rather than a recommended practice. I don't know enough to say yet. however, database connection information is stored in a .yml file in the application folder. Really? No centralized database connection information? If someone more experienced with Rails reads this and can correct me in this, I'd love to hear it. At work, we recently moved our production databases to new servers and changes user permissions, login information, and even the ports used to connect to the databases. Thanks to ColdFusion's centralized Datasource Manager, it was a near-painless and fairly simple operation to make sure that our websites didn't start failing. With the large number of web application we support, even using automated tools to change connection information in each application would have been a chore. I wonder if it would be possible to use symlinks on *nix to help with this some.
Along the lines of database stuff that I want to read more on before forming a firm opinion, a word or two on a command that will be more familiar to any Rails readers I may have than CF readers. rake db:migrate
Here's the scoop, as I understand it. When you create a model object in Rails- post and comment, for instance- a database migrate object is created. The "rake db:migrate" command will apply changes to the database, based on the model objects you have made. Post and Comment become tables and the attributes you have given those objects become fields. If you change those attributes, you can update your migration so that your database stays up to date with your model.
It seems convenient, but I don't know that I like it much. I used the example of Post and Comment for a reason- there's a relationship between these two tables in a database. A relationship that Rails' migrate tool doesn't appear to create. What you get with Rails is two seperate tables, whereas I would also create the Primary/Foreign key relationship, and probably put an index (possibly a clustered index) on the foreign key of the Comment table. A web app's big performance bottleneck is the database. The more effecient the database, the better. While I can certainly add that relationship in myself after migrate has created the tables (and certainly would), however I don't like having a tool that handles *most* of my database changes, but not all of them. I'd rather just generate SQL scripts from the database definition and save those scripts in source control somewhere.
Are these dealbreaker issues?
Nope.
Am I pretending to fully understand all of them?
Nope. Still learning, and I expect my first opinions to change as I learn more.
Am I done?
Yeah- for now.
Subscribe to:
Post Comments (Atom)
> A URL is a Uniform Resource Locater, and to me, that means a file on a webserver.
ReplyDeleteYeah, that was true until, oh, 1995 or so :-)
Speaking to another point, you're also missing the fact that migrations contain *whatever you want them to*, which can include arbitrary SQL statements to execute. And migrations are wonderfully handy when you're setting up another dev machine, installing an app on a shared system for testing, etc.
In any case, have fun exploring!
Good to know. I kind of wondered what all could go into a migration.
ReplyDeleteI like the idea of having a tool to handle database changes. That's one of the things that really caught my eye.