Propel ORM fails to query on the production environment because the database it connects to has case-sensitivity enabled (linux/ubuntu). Since the db is managed by another organization, it's harder to get it fixed than to make the changes to the code from our end.
Is there a way to force Propel ORM to use case-sensitive names?
Thanks!
Propel has a Map directory inside the generated files. The directory has all the mappings of table and column names which propel uses onto what MySQL uses.
We solved our problem by writing a simple python script that corrects the case-sensitivity as per our requirements.
Each file inside the Map directory corresponds to the mapping for one table. Our script opened each file one by one and replaced the each mapping with our specific requirement (which was to make table names upper case):
Here's the RegEx we used to match table name mapping:
"(\s*const TABLE_NAME = ')([a-zA-Z_]+)(';)"
RegEx for matching column mapping inside each file:
"(\s*\* the column name for the.*\s*\*\/.*\s*const [a-zA-Z_]+ = ')([a-zA-Z_]+)(\.[a-zA-Z_]+)(';)"
Related
I have a scala application that manages multiple MySQL database schemas, which includes modifying (adding, renaming, etc.) tables. The commands are issued over a connection pool that connects to a generic management database in the database server.
Because the application is designed to be cross-database, I use JOOQ to render SQL queries (execution is done via a separate JDBC module).
I experience issues with JOOQs alterTable(...).renameTo(...) DSL - consider the following example:
We have a table "TestTable" in database "TestDatabase". Let's say I want to rename that table simply to "Foo", keeping it in "TestDatabase".
This code:
...
val context = DSL.using(SQLDialect.MYSQL_5_7)
val query = context
.alterTable(table(name("TestDatabase", "TestDatabase")))
.renameTo(name("TestDatabase", "Foo"))
...
Generates: ALTER TABLE `TestDatabase`.`TestTable` RENAME TO `Foo`
However, since the connection pool I'm using is connected to my management database, it just renames the table to "Foo" and moves it to my management database. I would have expected the SQL to be: ALTER TABLE `TestDatabase`.`TestTable` RENAME TO `TestDatabase`.`Foo`. I tried a variety of alternatives to invoke the .renameTo method and convice it to use the fully qualified name, to no avail:
.renameTo(table(name(...) -> same behaviour.
.renameTo("`TestDatabase`.`Foo`") -> Escapes the name with backticks, treats it as one name instead of a qualified name.
I'm wondering if I'm missing something, if this is intended behaviour, or maybe even a bug or design shortcoming of JOOQ.
Is there a way to rename the table using fully qualified names?
Thank you!
That's a bug in jOOQ: https://github.com/jOOQ/jOOQ/issues/8042
Your workaround is close. This doesn't work:
.renameTo("`TestDatabase`.`Foo`")
As you've noticed, behind the scenes, the DSL.name() API is used to wrap the target name, because the renameTo() method doesn't implement the plain SQL templating API. You can, however, explicitly use plain SQL templating by writing as a workaround:
.renameTo(table("`TestDatabase`.`Foo`"))
Why are these important, what effect do they have on the database at hand?
Isn't the "schema" already decided at that point, as it exists in the database?
What exactly is a "catalog"? What kind of variable/input is the JPA catalog field expecting? Also, same question for the "schema" field.
Catalogs and schemas are "namespaces" that you define on the server side of the database. Some databases contains schemas, some contains catalogs, and some contains both. When logging in with a specific user, some databases defaults the schema/catalog to the user's namespace, causing the table to not be visible to other users, thus, causing the need to use a "common" namespace. So, depending on the database you are using to back your data, you might want to ignore those settings.
For MySQL, you might want to ignore those settings. This is because the "database" part of the JDBC URL (the one after the last slash) points to the database name, which is semantically identical to schema (for MySQL).
I'm trying to setup my hibernate entity to auto create the table IFAS_util_max_object_v in that exact format. No matter what I try, I can't seem to get it to capitalize IFAS. Does anybody have any ideas?
This is what I've tried.
#Table(name="\"IFAS_util_max_object_v\"")
Also, I'm using mysql db.
What operating system are you using?
Mysql has a setting in the configuration file to determine if table names should be converted to lower case. As the tables correspond to files on the disk with the table name they are converted to lower case when using Windows as Windows file names are case insensitive. So it is impossible when using Windows.
You can read here about the details.
I have a dataset with a lot of columns I want to import into a MySQL database, so I want to be able to create tables without specifying the column headers by hand. Rather I want to supply a filename with the column labels in it to (presumably) the MySQL CREATE TABLE command. I'm using standard MySQL Query Browser tools in Ubuntu, but I didn't see in option for this in the create table dialog, nor could I figure out how to write a query to do this from the CREATE TABLE documentation page. But there must be a way...
A CREATE TABLE statement includes more than just column names
Table name*
Column names*
Column data types*
Column constraints, like NOT NULL
Column options, like DEFAULT, character set
Table constraints, like PRIMARY KEY* and FOREIGN KEY
Indexes
Table options, like storage engine, default character set
* mandatory
You can't get all this just from a list of column names. You should write the CREATE TABLE statement yourself.
Re your comment: Many software development frameworks support ways to declare tables without using SQL DDL. E.g. Hibernate uses XML files. YAML is supported by Rails ActiveRecord, PHP Doctrine and Perl's SQLFairy. There are probably other tools that use other format such as JSON, but I don't know one offhand.
But eventually, all these "simplified" interfaces are no less complex to learn as SQL, while failing to represent exactly what SQL does. See also The Law of Leaky Abstractions.
Check out SQLFairy, because that tool might already convert from files to SQL in a way that can help you. And FWIW MySQL Query Browser (or under its current name, MySQL Workbench) can read SQL files. So you probably don't have to copy & paste manually.
I have data access object that have been generated by SqlMetal, however the database is created by running a sql script.
Is there an easy way to verify that all table and columns names and type matches the attributes on the classes that SqlMetal created?
I guess the easiest way to do this would be to have some kind of version number hidden in a config table in your schema. Then on runtime check the version number returned.
Much easier than doing a full scan. Set the version number in your SQL script and somewhere in your data access object