The problem with hibernate is, you need to put the database info (username/pw etc) in an xml file. However, if you deploy your app on Amazon web services, e.g on Beanstalk, you get the db info passed in via System.getProperty("RDS_DATABASE_USER"), etc. The advantage is, if more instances of your app are created, the db info is passed on automatically, without having to manually edit config files.
Is there a way to pass the db info to hibernate at runtime? If not, is there another good ORM library for java, to which you can pass this info at runtime? I'm using MySQL.
As a matter of fact, the method PersistenceUtil.createEntityManagerFactory allows you to provide a properties map. Using this map you can provide the user name and password in dynamic way.
How you do this may well depend on what specific frameworks you are using.
Based on the tags in your question it is not clear if you are using Hibernate or if you are using OpenJPA.
The Open JPA documentation in the section Obtaining an EntityManagerFactory provides the list of properties you could use.
Map<String,String> properties = new HashMap<>();
properties.put("openjpa.ConnectionUserName", "userName");
properties.put("openjpa.ConnectionPassword", "password");
EntityManagerFactory emf = Persistence.createEntityManagerFactory("MyPersistenceUnit",properties);
Hibernate supports a similar set of properties. Most probably you already have them in your persistence.xml file.
Some dependency injection frameworks, like Spring, don't even require a persistence.xml file and can read such properties dynamically from some other places, like environment variables.
Related
Is there any way to Load the database schema from .sql or json or textfile to create the ORM mapping with JPA/Hibernate to database in spring-boot while starting up the server.
Spring Boot enables you to use database migration tools such as Liquibase and Flyway, you can read more about that on Spring's official documentation.
Edit: From the docs
85.5 Use a Higher-level Database Migration Tool
Spring Boot supports two higher-level migration tools: Flyway and Liquibase.
85.5.1 Execute Flyway Database Migrations on Startup
To automatically run Flyway database migrations on startup, add the org.flywaydb:flyway-core to your classpath.
The migrations are scripts in the form V__.sql (with an underscore-separated version, such as ‘1’ or ‘2_1’). By default, they are in a folder called classpath:db/migration, but you can modify that location by setting spring.flyway.locations. This is a comma-separated list of one or more classpath: or filesystem: locations. For example, the following configuration would search for scripts in both the default classpath location and the /opt/migration directory:
spring.flyway.locations=classpath:db/migration,filesystem:/opt/migration
You can also add a special {vendor} placeholder to use vendor-specific scripts. Assume the following:
spring.flyway.locations=classpath:db/migration/{vendor}
Rather than using db/migration, the preceding configuration sets the folder to use according to the type of the database (such as db/migration/mysql for MySQL). The list of supported databases is available in DatabaseDriver.
FlywayProperties provides most of Flyway’s settings and a small set of additional properties that can be used to disable the migrations or switch off the location checking. If you need more control over the configuration, consider registering a FlywayConfigurationCustomizer bean.
Spring Boot calls Flyway.migrate() to perform the database migration. If you would like more control, provide a #Bean that implements FlywayMigrationStrategy.
Flyway supports SQL and Java callbacks. To use SQL-based callbacks, place the callback scripts in the classpath:db/migration folder. To use Java-based callbacks, create one or more beans that implement Callback. Any such beans are automatically registered with Flyway. They can be ordered by using #Order or by implementing Ordered. Beans that implement the deprecated FlywayCallback interface can also be detected, however they cannot be used alongside Callback beans.
By default, Flyway autowires the (#Primary) DataSource in your context and uses that for migrations. If you like to use a different DataSource, you can create one and mark its #Bean as #FlywayDataSource. If you do so and want two data sources, remember to create another one and mark it as #Primary. Alternatively, you can use Flyway’s native DataSource by setting spring.flyway.[url,user,password] in external properties. Setting either spring.flyway.url or spring.flyway.user is sufficient to cause Flyway to use its own DataSource. If any of the three properties has not be set, the value of its equivalent spring.datasource property will be used.
There is a Flyway sample so that you can see how to set things up.
You can also use Flyway to provide data for specific scenarios. For example, you can place test-specific migrations in src/test/resources and they are run only when your application starts for testing. Also, you can use profile-specific configuration to customize spring.flyway.locations so that certain migrations run only when a particular profile is active. For example, in application-dev.properties, you might specify the following setting:
spring.flyway.locations=classpath:/db/migration,classpath:/dev/db/migration
With that setup, migrations in dev/db/migration run only when the dev profile is active.
85.5.2 Execute Liquibase Database Migrations on Startup
To automatically run Liquibase database migrations on startup, add the org.liquibase:liquibase-core to your classpath.
By default, the master change log is read from db/changelog/db.changelog-master.yaml, but you can change the location by setting spring.liquibase.change-log. In addition to YAML, Liquibase also supports JSON, XML, and SQL change log formats.
By default, Liquibase autowires the (#Primary) DataSource in your context and uses that for migrations. If you need to use a different DataSource, you can create one and mark its #Bean as #LiquibaseDataSource. If you do so and you want two data sources, remember to create another one and mark it as #Primary. Alternatively, you can use Liquibase’s native DataSource by setting spring.liquibase.[url,user,password] in external properties. Setting either spring.liquibase.url or spring.liquibase.user is sufficient to cause Liquibase to use its own DataSource. If any of the three properties has not be set, the value of its equivalent spring.datasource property will be used.
See LiquibaseProperties for details about available settings such as contexts, the default schema, and others.
There is a Liquibase sample so that you can see how to set things up.
Spring also supports a database initialization on its own, the official docs are here.
Spring Boot can automatically create the schema (DDL scripts) of your DataSource and initialize it (DML scripts). It loads SQL from the standard root classpath locations: schema.sql and data.sql, respectively.
Apache Cayenne keeps a "...project.xml" file within the resources directory. This file contains the password to the database. This is a problem because the [deployment server] password should not visible to developers. Further, it would need to be a different user/password and connection to a different database during development.
What is the best practice to manage this "...project.xml" when using Cayenne? Any suggestions?
EDIT:
Instead of putting the database connection info (incl. password) into the XML file, is it possible to inject the info programatically into the DataSource object? If so, I can load the info from a config file when the app starts and then inject it.
Yes of course. There is a "cayenne.jdbc.password" property that can be used to define DataSource password in runtime. It can be applied in two alternative ways:
As a system property on command line:
java -Dcayenne.jdbc.password=xxxxx
Via injection:
ServerModule.contributeProperties(binder)
.put(Constants.JDBC_PASSWORD_PROPERTY, "xxxxx");
This and other config properties are documented here.
This is fairly straight forward with a simple Spring DAO approach. However, using MyBatis, is there a way to setup multiple potential datasources?
The best approach I can think of is to use an ArraList of a Bean each containing datasource.driverclass,datasource.url, datasource.username, datasource.password etc.
The values for the datasources are stored in individual properties files. There could be 1 or 10 of these property files (or more).
So for example, one application startup all the property files would be loaded one at a time into an ArrayList. Then, based on the NAME=value line from the property file, we would know which datasource to hit.
So http:localhost:8080/name=db1
... would access all the data from the datasource configured with the name "09". Each property file would contain:
name=db1
datasource.driverclass=jdbc:sqlserver
datasource.url=jdbc:sqlserver://localhost:1433;databaseName=someDBname
datasource.username=user1
datasource.password=pass1
So the identifier here is "name=db1".
Would the best approach from a MyBatis implementation utilise an ArrayList of Beans?
Here are some leads if you want to keep up with multiple DB:
Anyway, I would say datasources shall be managed in the server confiquration instead of in the App.
Then Mybatis main configuration file must be placed in a location added to the classpath, but outside of the app package, because every new datasource must be referenced there inside an environment element.
And for every user request or session (in case of a web app), the configuration will be parsed because SqlSessionFactoryBuilder.build(reader, environment=NAME); must be called to choose the environment (=> the DB).
I ended up using a hierarchical application.yml file detailing the multitenant connection values, based on a selected tenant code.
I have created the Databse dropdown list using the JSP. If I select anyone of the database and it should be pointing to the database and then the query written should be executed to the database which I have selected.
Present work done.
Now I have created statically like how much database I have that much Properties are written in the property file and all the credentials will be taken by Context.xml so how can i create it dynamically so that I dont want to write the different properties for each database and i dont want to create the different session nor I don't want to restart the server when ever I select the DataBase ?
In the property file I have written the different properties for each and every databases and in XML also we have created the different sessions for each and every databases so i donit need to write the different sessions nor restart my Server after the selection of the Database
My question is to can we implement as per my requirement.??????
And another thing for the different database we have created the interface and for that interface we have created the implementation
I believe there is nothing prohibit you from programmatically creating all DB related artifacts (e.g. Datasource, JdbcTemplate, EntityManager etc), and perform transaction management programmatically. Of course you will be giving up a lot of facilities provided by the container (or, I should say, still achievable with high cost)
Another idea I believe will work (though I haven't tried) is to create a child application context from your main app context. The child context will prepare/lookup datasource etc base on properties. Your parent context will of course need to provide correct properties to the child context. By doing so, it should be easy to leverage on feature provided by Spring.
I have written an application using java, camel, spring, shiro, c3p0 and jpa.
This application needs to connect to some web services and some db and it has now a static configuration using classic spring propertyplaceholders and .prop property files.
I inject properties in java classes using #Value annotations and I define datasources using spring with ${} placeholders.
In the configuration there are url,username,password for web services and database,url,username,password for datasource.
Now I need to do a dynamic/multi tenant configuration. I mean that each "customer" can have his set of passwords and that these login/passwords can change over time.
Using shiro I can add to the Subject some data, so I can add current properties to it and get them where I need.
But how can I continue to use #value annotations?
And, most important question, how can I change datasources parameters at runtime?
I see in c3p0 documentation that using getConnection(username,password) with a new pair of username and password creates a new pool and close the old. But I do not use getConnection because only the EntityManager uses datasource.
Please help me!
Thanks,
Mario
After a lot of searching I think I can do in this way:
for properties use DynamicCombinedConfiguration from commons configuration, but I do not know how to tell it to read the tenant id from Shiro Subject
for JPA use AbstractDataSource from spring, but again I do not know if I can read the tenant id from Shiro Subject
Can you tell me if I am pointing in the right direction?
Thanks again,
Mario