2

Answer says, not to trust hibernate.hbm2ddl.auto setting for production.

My understanding of using ORM:

1) To avoid designing & normalising DB schema at database layer(say RDBMS). In mongoDB world, ODM is used.

2) To avoid embedding SQL query language in code(say java).

3) To just think about storing and retrieving objects(in OOP sense)

Running DDL scripts breaks the purpose of using ORM tool and looks similar to JDBC approach except it provides the SQL dialect for vendor specific database.

For production, Can running of DDL scripts mandatory for safety?

overexchange
  • 15,768
  • 30
  • 152
  • 347
  • "Running DDL scripts manually breaks the purpose of using ORM tool." - says who? (Not that you have to run them manually, you can use tools like Flyway to manage the execution of your DDL scripts) – Erwin Bolwidt Jan 05 '18 at 07:06
  • @ErwinBolwidt Ah manually or otherwise, does not matter. ORM is mainly to avoid this phase – overexchange Jan 05 '18 at 07:11
  • 2
    No it's not. You seem to have misunderstood what ORM is for. – Kayaman Jan 05 '18 at 07:13
  • ORM tools in Java mostly (always?) run _on top of_ JDBC. They are an abstraction that means that you can interact with objects instead of writing SQL queries, the automatic dialect-translation is a very small feature of what they provide. JPA specifically (which Hibernate implements) also aids you with session and transaction management. – Raniz Jan 05 '18 at 07:21
  • @Raniz Is ORM not to avoid thinking at database layer? 1) To avoid designing & normalising DB schema in RDBMS world 2) To avoid embedding SQL query language in code 3) To just think about storing and retrieving objects(in OOP sense) – overexchange Jan 05 '18 at 07:33
  • 1
    ORMs are absolutely not about _"To avoid designing & normalising schema in RDBMS world"_. It has more to do with _2_ and _3_ though. An ORM is there to enable you to write object-oriented code to interact with your database. You should still _design your database first_ and then map your classes after how the database is structured - _not the other way around_. Using an ORM doesn't in any way prevent you from issues with badly structured tables. – Raniz Jan 05 '18 at 07:39
  • @Raniz Then, what is the purpose of `hibernate-mapping` tag in `hibernate.cfg.xml` that lists all persistence classes. Relationships between those classes should be taken care by ORM for creating relationship tables as well. – overexchange Jan 05 '18 at 07:43
  • If you really don't want to work with schemas I suggest you look at other types of databases like schema-less databases or object-oriented databases - though these come with issues of their own. There's no silver bullet when it comes to data storage; all solutions have their own positives and negatives. – Raniz Jan 05 '18 at 07:44
  • @Raniz Am a good DB designer given requirement but new to Hibernate. So, trying to understand, how much a hibernate user can rely with its given abstraction? *Object relational impedence mis-match* is always a big challenege for DB designers – overexchange Jan 05 '18 at 07:46
  • I'm not going to draw out this discussion any longer, but the mappings you give to Hibernate doesn't describe your entire table - you can even have multiple classes that map to the same table in different ways (if you want to exclude some columns for example). They describe how Hibernate should map data between tables and classes but does not describe things such as indexes, character encodings or even constraint checks. I suggest you read up on what an ORM is and isn't because you seem to have gotten the wrong impression of that. – Raniz Jan 05 '18 at 07:52

2 Answers2

3

Running DDL scripts manually breaks the purpose of using ORM tool.

No, it does not.

An Object-Relational Mapping tool is tool that helps translate data from your tables into objects that you can use in your object-orianted programming language - it has nothing to do with database administration.

Hibernate can generate a DDL based on what your classes look like right now, but it has no sense of history.

If all you're doing is adding new columns or tables you'll probably be fine but the minute you rename a column you're out of luck because Hibernate will see the old column and won't find a mapping to it so it will remove it and then create a new column using the new name. If you have a non-null requirement on that column you're screwed because you can't tell Hibernate what the default value is (well, there's a hack but please don't do this.)

You're also very limited in how you can change the types of columns - if the contents of the column can't be translated automatically by the database you're out of luck.

As an example we switched our databases from storing UUIDs in binary to storing it as a VARCHAR a while back and we had to manually convert them from binary to hexadecimal notation becasue MySQL can't do that automatically - you'd be properly screwed if you tried to do that with Hibernate's auto-DDL.

There's also no way of telling Hibernate where to create indexes - you'll get an index on each primary key column but if you want extra indexes you'll have to add these manually.

The DDL auto-generation of Hibernate is good for validating that your classes map correctly to your tables, but it should never be used to alter your production databases.

So to answer your question:

For production, does manual run of DDL scripts mandatory for safety?

Yes! And I recommend you use a management tool like Liquibase or Flyway to aid with it.

Raniz
  • 10,882
  • 1
  • 32
  • 64
  • Can you share some resource that talks about what is and isn't hibernate? – overexchange Jan 05 '18 at 08:47
  • I can't really find any resources that discuss what Hibernate _is not_, but if you read up on introductions on ORM, JPA and Hibernate you'll get a good idea of what problems they were designed to solve (i.e. relational data access and manipulation in RDBMS). – Raniz Jan 05 '18 at 10:03
2

Yes, they are required. If you want to work efficiently that is.

Running DDL scripts manually breaks the purpose of using ORM tool

No it doesn't. ORM stands for Object Relational Mapping, meaning it maps the relational data of the RDBMS to Objects. Nowhere does it imply that the database schema must be changed by the ORM, even though the possibility exists (and works in very simple cases).

Besides you're not going to be running anything manually. There are database migration/refactoring products like Flyway and Liquibase that attempt to solve the problem of a database schema changing over time. They're also separate products, so you don't need to care whether you're using Hibernate or some other method of data access. They also try to provide some amount of transactionality, meaning you can revert a change to the schema in some cases.

In any non-trivial project one would try to make sure they can improve the database without being permanently locked into a legacy schema, as well as making incredibly sure that the data stays safe. A proper tool designed for that purpose makes it a lot easier, an ORM's half-baked mechanism does not.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
  • So, Can I say ORM is mainly to run DML operations(for safety) using Hibernate but not DDL? – – overexchange Jan 05 '18 at 22:08
  • It has nothing to do with safety. It's about convenience. In toy projects you can also have the schema update automatically, but it's not a viable option except in the simplest of cases. – Kayaman Jan 06 '18 at 07:58
  • In production, Is it more convenient to perform DML operations using Hibernate? and run DDL scripts separately – overexchange Jan 06 '18 at 09:38