Page 1 of 2 12 LastLast
Results 1 to 20 of 27
  1. #1
    berlindutza is offline Member
    Join Date
    Aug 2009
    Posts
    25
    Rep Power
    0

    Default How to generate database schema automatically through Hibernate

    I've read that with the object mapping in place and the Hibernate configuration file set up correctly, I have everything I need to generate a script for my application by invoking the export DDL task. But I don't know where I could find it...
    I'm using a mysql database, Eclipse and up until now I have created the tables by myself.

    Where can I find the export DDL task?

    Thanks!

  2. #2
    FON
    FON is offline Senior Member
    Join Date
    Dec 2009
    Location
    Belgrade, Serbia
    Posts
    368
    Rep Power
    5

    Default

    I'm not sure what you need exactly.

    You have created tables in DB?
    You are now looking for a way to use reverse engineering - create code from DB ?

    If you need that, I will post you nice and clean instructions how to do it using :
    "Hiberante tools and Eclipse Plugins"

    waiting for your answer

  3. #3
    berlindutza is offline Member
    Join Date
    Aug 2009
    Posts
    25
    Rep Power
    0

    Default

    I haven't created the tables.
    I want to automatically generate the code needed to create the table!
    I think I should use Hibernate Tools, but I don't how to do it!
    Last edited by berlindutza; 02-17-2010 at 07:52 PM.

  4. #4
    FON
    FON is offline Senior Member
    Join Date
    Dec 2009
    Location
    Belgrade, Serbia
    Posts
    368
    Rep Power
    5

    Default Hiberante tools and Eclipse Plugins

    OK I will post it to help you to set up all you need
    BUT I have example with reverse engineering - creating code from DB.

    Once you have all installed and set
    I hope you will figure out easily how to do finish your work


    Hiberante tools and Eclipse Plugins:
    (Install manual and Reverse engineering - create code from DB example)


    help:
    https://www.hibernate.org/hib_docs/t...l/plugins.html

    ---
    IN THIS FILE:
    0. my installed software
    1. install tools
    2. create hiberanate config file
    3. create hibernate console configuration and conn to DB
    4. reverse eng. from DB to:
    annotated java Entiry class
    Hibernate XML mapping - hbm.xml
    and more
    ---

    0. On my machine:
    Java 1.6 SDK
    eclipse-jee-galileo-win32 3.5
    MySQL 5.1
    MySQL JDBC Driver

    1. Download "HibernateTools-3.2.4.GA-R200905070146-H18"

    Download JBoss.org from SourceForge.net

    2. Install
    Unzip.
    Copy features to your eclipse features dir:
    C:\eclipse-jee-galileo-win32\eclipse\features
    Copy plugins and jars to your eclipse plugins dir:
    C:\eclipse-jee-galileo-win32\eclipse\plugins

    Run eclipse from command prompt with "-clean" command:
    cd C:\eclipse-jee-galileo-win32\eclipse
    eclipse -clean

    3. In Eclipse there is new 'perspective' - Hibernate.
    Also there are new wizards

    4. File => New => Other => Hibernate => 'Hibernate Configuration file'

    Create new config file: hibernate.cfg.xml


    5. Create 'Hiberante Console Configuration'

    (that uses previously crated config file in step 4.)

    (Done is step 4. if you checked [] 'Create a console configuration '
    or do it manually
    File => New => Other => Hibernate => 'Hibernate Console Configuration')

    Create connection do some DB:
    tab Main => Database connection => New => MySQL
    drivers : MySQL JDBC Driver
    URL: jdbc:mysql://localhost:3306/database_name
    test coonection!

    Now switch to Hibernate perspective.
    'Hiberante Console Configuration' becomes root in Hibernate Configurations window.
    Right mouse click on it and click Edit to edit it more.


    6. Reverse engineering - create code from DB :

    Eclipse main menu Run => Hibernate code Generation => Hibernate code Generation configurations

    tab Menu =>
    Console Configuration - choose one created in step 5.

    Outout directory: Browse and create one
    Reverse eng from JDBC Connection: checked
    package: org.something

    Exporters tab= >
    General settings:
    check Java 5 syntax for plain java syntax
    Check Generate EJB3 annotations for annotaions
    Exporters:
    Click as you like
    Click Apply
    Click Run.

    7. return to Java perspective and see cretaed Java Entity classes ant other

    --

    good luck ;)

  5. #5
    Aseem is offline Senior Member
    Join Date
    Mar 2009
    Location
    USA
    Posts
    127
    Rep Power
    0

    Default

    try using Netbeans.. it will create everything for you.
    - all you need to have a table in db.
    - it will create POJO class
    - mapping file
    - configuration file
    -helper class

    very handy IDE.

    FON, how r u mate? Been a while ..!

  6. #6
    berlindutza is offline Member
    Join Date
    Aug 2009
    Posts
    25
    Rep Power
    0

    Default

    Thank you!
    I will try to do as you say!
    I will anounce about the result!

  7. #7
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,953
    Rep Power
    19

    Default

    Hang on, aren't you two going the wrong direction?

    I thought the OP was asking how to use Hibernate to auto-generate the TABLES in a db (or at least the DDL scripts) from the config files? Not how to generate the config and classes from an existing table...

  8. #8
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Just set the hibernate.hbm2ddl.auto property to create or update in your persistence.xml or config file.

  9. #9
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,953
    Rep Power
    19

    Default

    Or don't rely on Hibernate to do it for you...:)

    The idea of auto-generating tables fills me with horror...:)

    You've presumably designed the DB, so you must be able to get the DB to generate the DDL for you.

  10. #10
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Actually the point of JPA is that you work with object graphs rather than tables and let the providers generate and map those to tables according to the chosen database implementation.

  11. #11
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,953
    Rep Power
    19

    Default

    Well, yes. But you still ought to actually design your db schema.
    The data in that db is unlikely to be accessed by a single app, so a properly desgined schema is pretty important.

  12. #12
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    It's better to put as much of that in the entities themselves as possible. This makes your application more portable as long as you stick to the JPA spec settings.

  13. #13
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,953
    Rep Power
    19

    Default

    Have to disagree.
    It ends up viewing the db as almost a blackbox.
    Makes tuning it in a portable way a bit of a sod as well.
    Having it as a set of DDL scripts, complete with the recommended set up, for me males far more sense.

    After all, you've just spent thousands on your db license...you want to make sure it's working properly.

  14. #14
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Perhaps we are talking about different things.
    JPA allows you to model your business objects and relationships between them using plain Java objects. You specify your relationships in entities according to the actual real world relationships not to some normalization norms. The persistence provider transforms that into normalized tables using the EE spec. The bean developer does not directly normalize the tables himself (it's not his knowledge domain). He simply refines the nature of the relationships and the persistence provider knows how to produce the best tables for those relationships.
    If you create the tables directly and normalize them yourself then you are back to the pre JPA days and are now faced with the old problems of mapping those tables to objects which you don't need in your EJB layer.
    The DBA role is not one of the seven EJB roles because it is assumed as part of the persistence provider.
    Sure you can add extra tuning to the schema if you want, but that's outside the EE spec and should not affect (or override) the schema already generated by the persistence provider.

  15. #15
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,953
    Rep Power
    19

    Default

    That's as may be, but it's that black box aspect of the db that I am opposed to.
    It almost invariably results in poor code from a db perspective.

    Or, put another way, if you're going to work with databases then learn about them...

    The db is not simply a data dump, which is where this invariably leads. And, as I say, you've spent thousands (or tens of thousands) on your db...may as well get value for money from it.

  16. #16
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    The persistence should be a black box as far as the application is concerned.
    Just because you spend money on something doesn't mean the application should be made any less portable. You don't have to be a DBA to develop applications. That is why there are seven distinct enterprise roles. If you do decide to use JPA then you must think model objects not database tables.

  17. #17
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,953
    Rep Power
    19

    Default

    As far as the app is concerned, maybe...though I would argue that the persistence layer should not view the thing it is persisting to as a black box.

    However the db, in terms of development, should not be a black box. That is plain daft.

    Again, the idea that you can take App-A which has a persistence layer and simply deploy it against a MySQL db, and then deploy the same thing against an Oracle server, and then again against a SQL Server instance, without having to actually work with the database is nonsense. Yes, the front end is portable, but the backend (into the db) should not be viewed that way.

    I've seen too many failures which relied on that aspect, and too many clients (including developers) complaining that the app doesn't work well against Oracle, when it was perfectly fine against MySQL, to know that this black box view of the back end is a Bad Thing. The db is part of the app...you have to know how it works...at least someone has to.

  18. #18
    r035198x is offline Senior Member
    Join Date
    Aug 2009
    Posts
    2,388
    Rep Power
    8

    Default

    Quote Originally Posted by Tolls View Post
    As far as the app is concerned, maybe...though I would argue that the persistence layer should not view the thing it is persisting to as a black box....
    It does not. The persistence provider uses RDBM specific APIs and settings.

    Quote Originally Posted by Tolls View Post
    ...
    However the db, in terms of development, should not be a black box. That is plain daft.
    ...
    You will need to qualify what you mean by "development". Developing what?
    The view and service layers for example should not be aware of the backend implementation. That's the whole point of the DAOFactory pattern.

    Quote Originally Posted by Tolls View Post
    ...Again, the idea that you can take App-A which has a persistence layer and simply deploy it against a MySQL db, and then deploy the same thing against an Oracle server, and then again against a SQL Server instance, without having to actually work with the database is nonsense. ..
    Again you will need to qualify what you mean by "work with the database". You should not have to create new tables or add new costraints because you switched databases.

    Quote Originally Posted by Tolls View Post
    ...I've seen too many failures which relied on that aspect, and too many clients (including developers) complaining that the app doesn't work well against Oracle, when it was perfectly fine against MySQL..
    That is because of incompetence on the parties involved and not because of JPA. You will get that more on applications developed without JPA rather than those developed with JPA. That is one of the many advantages of JPA.

    Quote Originally Posted by Tolls View Post
    ...you have to know how it works..at least someone has to.
    No you don't really, the persistence provider should. EJB providers (Java developers) do not have to be DBAs.

  19. #19
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Posts
    11,953
    Rep Power
    19

    Default

    Quote Originally Posted by r035198x View Post
    It does not. The persistence provider uses RDBM specific APIs and settings.
    Sorry, that doesn't generally work. You are still reliant on auto-generated stuff. As with (for example) a GUI generator in an IDE (say Netbeans), the code is generally less than impressive. Have you seen some Hibernate queries?

    Quote Originally Posted by r035198x View Post
    You will need to qualify what you mean by "development". Developing what?
    The view and service layers for example should not be aware of the backend implementation. That's the whole point of the DAOFactory pattern.
    I develop apps. An app has a front end, a business layer and a persistence layer. Yes, each part should not have to care (beyond the specification of interfaces) how the other bits work. The back end, though, should not be left to some auto-generated stuff...it should not treat (again) the db as a black box. It's a sure fire way to get yor DBA annoyed with you...:)

    Quote Originally Posted by r035198x View Post
    Again you will need to qualify what you mean by "work with the database". You should not have to create new tables or add new costraints because you switched databases.
    But you do have to see how queries perform, and where to stick indexes. Different dbs will treat a query differently. Storage, partitioning, indexes, views, etc etc. These are not things that can be generated. They need tuning. And each db will be different.

    [QUOTE=r035198x;105348]
    That is because of incompetence on the parties involved and not because of JPA. You will get that more on applications developed without JPA rather than those developed with JPA. That is one of the many advantages of JPA.
    [QUOTE]

    Nope, see above. Each db is different. Shifting from one to another is not a simple task. As I say, the data in the db is rarely used by a single app. That's where the JPA falls down, to be honest. Someone moving to Oracle, and spending the big bucks on it, will expect performance improvements over MySQL. They will get it if the actually tune their app, but to expect an app to fall onto Oracle and work outright with the best performance is not going to happen.

    Quote Originally Posted by r035198x View Post
    No you don't really, the persistence provider should. EJB providers (Java developers) do not have to be DBAs.
    In the same way that you get byzantine Swing code with an GUI generator, you get the same with the providers. In essence, you're wasting your db.

  20. #20
    FON
    FON is offline Senior Member
    Join Date
    Dec 2009
    Location
    Belgrade, Serbia
    Posts
    368
    Rep Power
    5

    Default

    Quote Originally Posted by Tolls View Post
    Hang on, aren't you two going the wrong direction?

    I thought the OP was asking how to use Hibernate to auto-generate the TABLES in a db (or at least the DDL scripts) from the config files? Not how to generate the config and classes from an existing table...


    Quote Originally Posted by berlindutza View Post
    I haven't created the tables.
    I want to automatically generate the code needed to create the table!
    [U]I think I should use Hibernate Tools, but I don't how to do it!

    There is no misunderstanding here.
    I wrote twice in my posts that example is "reverse DB to code example",
    and reason is simple - i had that manual already written before by myself,
    and there was complete Hibernate tools install instruction inside,
    idea was to help OP start using tools easily.

    @berlindutza
    How was that installation ?

Page 1 of 2 12 LastLast

Similar Threads

  1. Replies: 0
    Last Post: 12-01-2009, 10:01 PM
  2. problem with getting alll schema names from database
    By sandeepsai17 in forum New To Java
    Replies: 1
    Last Post: 07-21-2009, 12:38 PM
  3. Automatically Generate an XML file
    By svpriyan in forum XML
    Replies: 2
    Last Post: 06-25-2009, 05:46 AM
  4. Hibernate with multiple database
    By Marty in forum JDBC
    Replies: 3
    Last Post: 12-23-2008, 12:57 PM
  5. Generate <UL> list from Database with sub categories
    By itsnexgen in forum New To Java
    Replies: 4
    Last Post: 09-29-2008, 07:53 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •