I am working with a MySQL database that has capitalized table/field names like Users, Institutions, etc. Because the operating system of the database host is Linux, identifiers (like the table names) are treated as case sensitive. So, failing to capitalize a table name will result in a table does not exist error.
The problem I am trying to solve is that ActiveRecord always constructs identifiers in lower case. So, for example, if use the "find" method to grab the first record from the Institution table, the resulting SQL will look like:
SELECT `institutions`.* FROM `institutions` LIMIT 1
This, of course, results in a MySQL error in a Linux environment because it is not case sensitive.
Any thoughts on how one might get around this issue?
Thanks in advance!
class Mouse < ActiveRecord::Base
set_table_name "Meece"
end
Should clear you right up I think.
Rails use convention over configuration to determine the name of the table from a model.
But you can always tweak the default to match your legacy databases.
Have a look here:
http://book.opensourceproject.org.cn/lamp/ruby/railscook/opensource/0596527314/i_0596527314_chp_3_sect_20.html
and here:
http://railsapi.com/doc/rails-v3.0.0/classes/ActiveRecord/Base.html#M001129
Related
I want to name my mysql table column names using camel case and create php classes from these mysql tables with the same camel case names. I will be generating these php classes automatically. I'm wondering if I can rely on column name case no matter what platform I run my application on. So for example, if I name one column name "FirstName", will I ever encounter a time where reading the column name from the database will product "firstname" or something like that?
Short answer is no.
The long answer is that case-sensitivity for some things in MySQL depend on the underlying operating system. (Unix being the sensitive one)
Here is the reference to the issue in the MySQL documentation.
Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database and table names. This means database and table names are not case sensitive in Windows, and case sensitive in most varieties of Unix. One notable exception is Mac OS X, which is Unix-based but uses a default file system type (HFS+) that is not case sensitive.
Also from the documentation on column names specifically:
Column, index, and stored routine names are not case sensitive on any platform, nor are column aliases. Trigger names are case sensitive, which differs from standard SQL.
MySQL is case sensitive in table and column names, and case in-sensitive in keywords.
But note that Windows is only case preserving, and file names are table names. (If you work on table "SalesAccounts" when you meant "Salesaccounts" then it will read OK on Windows and fail on Linux.
You should be OK with what you want to do, but
1) Test on Linux,
2) Test the tools you are using.
I'm currently moving my project to production and found an odd situation. The database was (unfortunately) created with object names in lowercase. Now, I'm acting on table all over my 100+ stored procedures/functions, not always keeping in mind the fact that I should use lowercase for table names.
I made a simple test:
select * from mytable ;
yields all the records in the table, whereas:
select * from Mytable ;
returns a "table does not exist" error.
Is there any solution someone could suggest besides going one by one through each and every stored procedure/function and correct the case of the table names?
Thanking in advance for any life-saving suggestion.
From the MySQL documentation on cases in identifiers:
In MySQL, databases correspond to directories within the data
directory. Each table within a database corresponds to at least one
file within the database directory (and possibly more, depending on
the storage engine). Triggers also correspond to files. Consequently,
the case sensitivity of the underlying operating system plays a part
in the case sensitivity of database, table, and trigger names.
I would probably take the time to make everything lower case because it will save you headaches further down the line. If you have a client with a decent editor like MySQL Workbench then you can do these replaces with a quick find and replace.
EDIT:
According to the documentation, you can try setting the lower_case_table_names system variable to 1, which will:
Table names are stored in lowercase on disk and name comparisons are
not case sensitive. MySQL converts all table names to lowercase on
storage and lookup. This behavior also applies to database names and
table aliases.
This might solve your problem if all of the table had been created with lowercase on disk.
I'm trying to push a brand new Ruby on Rails app to Heroku. Currently, it sits on MySQL. It looks like Heroku doesn't really support MySQL and so we are considering using PostgreSQL, which they DO support.
How difficult should I expect this to be? What do I need to do to make this happen?
Again, please note that my DB as of right now (both development & production) are completely empty.
Common issues:
GROUP BY behavior. PostgreSQL has a rather strict GROUP BY. If you use a GROUP BY clause, then every column in your SELECT must either appear in your GROUP BY or be used in an aggregate function.
Data truncation. MySQL will quietly truncate a long string to fit inside a char(n) column unless your server is in strict mode, PostgreSQL will complain and make you truncate your string yourself.
Quoting is different, MySQL uses backticks for quoting identifiers whereas PostgreSQL uses double quotes.
LIKE is case insensitive in MySQL but not in PostgreSQL. This leads many MySQL users to use LIKE as a case insensitive string equality operator.
(1) will be an issue if you use AR's group method in any of your queries or GROUP BY in any raw SQL. Do some searching for column "X" must appear in the GROUP BY clause or be used in an aggregate function and you'll see some examples and common solutions.
(2) will be an issue if you use string columns anywhere in your application and your models aren't properly validating the length of all incoming string values. Note that creating a string column in Rails without specifying a limit actually creates a varchar(255) column so there actually is an implicit :limit => 255 even though you didn't specify one. An alternative is to use t.text for your strings instead of t.string; this will let you work with arbitrarily large strings without penalty (for PostgreSQL at least). As Erwin notes below (and every other chance he gets), varchar(n) is a bit of an anachronism in the PostgreSQL world.
(3) shouldn't be a problem unless you have raw SQL in your code.
(4) will be an issue if you're using LIKE anywhere in your application. You can fix this one by changing a like b to lower(a) like lower(b) (or upper(a) like upper(b) if you like to shout) or a ilike b but be aware that PostgreSQL's ILIKE is non-standard.
There are other differences that can cause trouble but those seem like the most common issues.
You'll have to review a few things to feel safe:
group calls.
Raw SQL (including any snippets in where calls).
String length validations in your models.
All uses of LIKE.
If you have no data to migrate, it should be as simple as telling your Gemfile to use the pg gem instead, running bundle install, and updating your database.yml file to point to your PostgreSQL databases. Then just run your migrations (rake db:migrate) and everything should work great.
Don't feel you have to migrate to Postgres - there are several MySQL Addon providers available on Heroku - http://addons.heroku.com/cleardb is the one I've had the most success with.
It should be simplicity itself: port the DDL from MySQL to PostgreSQL.
Does Heroku have any schema creation scripts? I'd depend on those if they were available.
MySQL and PostgreSQL are different (e.g. identity type for MySQL, sequences for PostgreSQL). But the port shouldn't be too hard. How many tables? Tens are doable.
I need to build a Ruby on Rails database which can handle multiple “modules” which provide various related sets of functionality. I'd like some way of grouping the module tables by their modules, almost akin to namespaces.
Is the : character safe for use in table names with Ruby on Rails, and if not, what's a good alternative?
That really depends on the database provider. If you're using mysql or some other sql based database, I'd say that : isn't permitted, but what you can do is modify the migration file to name the table something like modulename_modelname. Then in the model itself you can specify the table name by calling set_table_name as documented here:
http://api.rubyonrails.org/classes/ActiveRecord/Base.html#method-c-set_table_name
That just looks dangerous and ugly to me. I'd stick with prepending something with underscores.
admin_users
admin_tools
supervisor_charts
etc
I had an model with an "end" column (datetime format), only to discover that Heroku crashes and burns with illogical Active Record errors whenever I attempted to reference the column in a query. I spent two hours trying to debug the extremely simple query, after which point I renamed the column to "end_at" and all of my problems disappeared.
Has anybody else experienced this issue? I'm curious of the reasoning behind this and hope that we can help others avoid the same mistake. A similar question has been asked before, but a clear answer was not presented.
BEGIN and END are reserved words in Oracle and SQL Server, but not sure why MySQL doesn't consider them as such.
However that PGError would appear to indicate that the database engine itself (and not any Ruby-related runtime) has indeed rejected the query because of the "end".
Reserved words (and names containing spaces) can be used if quoted - perhaps Active Record didn't quote the identifiers in the SQL which was generated.
I would look at the log in MySQL (http://dev.mysql.com/doc/refman/5.5/en/query-log.html) and see the statements generated.
And since the PGError means PostGreSQL and you mentioned Heroku (PostgreSQL 8.3) - I think this is because END is indeed a reserved word in PostgreSQL: http://www.postgresql.org/docs/8.3/static/sql-keywords-appendix.html
http://www.petefreitag.com/tools/sql_reserved_words_checker/?word=end
PostgresQL (which Heroku uses) reserves END as a keyword, so it is giving you a syntax error because your syntax is incorrect.
There are two options for fixing it:
If Heroku is breaking because ActiveRecord is not quoting column names, you can rewrite every query that uses that model to explicitly quote the "end" column so PostgresQL doesn't blow up.
Whether or not ActiveRecord quotes that column name by default, renaming the column something more descriptive (end_time, end_date, etc) and also not a reserved word in both the language you are writing the app in as well as a reserved word in the SQL engine you are using.