multiple/any Database-Module with jdbc

[gert]

Hey,

i want to use in my application any database, example hsql, mysql,
oracle, etc. . For the specified database-connection i think to write
modules. Have anybody samples or tricks for developing the function/
modules?
How registered itself the module on a application?


Thanks.

gp

 

[ck]

Hey,

i want to use in my application any database, example hsql, mysql,
oracle, etc. . For the specified database-connection i think to write
modules. Have anybody samples or tricks for developing the function/
modules?
How registered itself the module on a application?

Thanks.

gp

Are you aware about hibernate? http://www.hibernate.org

 

[ck]

Hey,

i want to use in my application any database, example hsql, mysql,
oracle, etc. . For the specified database-connection i think to write
modules. Have anybody samples or tricks for developing the function/
modules?
How registered itself the module on a application?

Thanks.

gp

Are you aware about hibernate? http://www.hibernate.org

 

[Lew]

Use JDBC, at least. (Frameworks that sit atop JDBC are a trivial extension of
the idea.)

Your code that uses JDBC will not change with different databases.

Put the database Driver class name and connection strings in a property file
and load the properties at program startup.

For a JDBC driver class name stored in a String variable "driver" you
"register ... the module" by

Class.forName( driver );

which loads the driver class and registers it with the DriverManager.

Check out the tutorials on JDBC.

-- Lew

 

[Guest]

Use JDBC, at least. (Frameworks that sit atop JDBC are a trivial
extension of the idea.)

It is rather difficult to write database code in Java that does not
use JDBC.

Your code that uses JDBC will not change with different databases.

That is the goal. It is even possible for simple database
usage. But for more advanced database usages it often becomes
very difficult.

As soon as you need something non standard SQL then it
becomes tricky.

Arne

 

[gert]

Hello Lew,

Use JDBC, at least. (Frameworks that sit atop JDBC are a trivial extension of
the idea.)

Your code that uses JDBC will not change with different databases.

yest i use it early.

Put the database Driver class name and connection strings in a property file
and load the properties at program startup.

For a JDBC driver class name stored in a String variable "driver" you
"register ... the module" by
Class.forName( driver );

ok, i have it so. I meant how does load the program the properties/
module at startup? How make it neatbeans to example? Read/scan the
program a directory where the modules there are?

i'm on the right way.


regards

gp

 

[Lew]

ok, i have it so. I meant how does load the program the properties/
module at startup? How make it neatbeans to example? Read/scan the
program a directory where the modules there are?

Use Properties files.

During initialization of the module load the JDBC driver using the property
for the DB driver that you define in your Properties file. Connect to the
database using properties defined in your Properties.

You will find what you need to know in the API docs for java.util.Properties.

-- Lew

 

[ck]

Use Properties files.

During initialization of the module load the JDBC driver using the property
for the DB driver that you define in your Properties file. Connect to the
database using properties defined in your Properties.

You will find what you need to know in the API docs for java.util.Properties.

-- Lew

In case you are planning to use Properties, you would need to put the
database queries and DML as well in the Properties file. In some
situations the DML and queries can be Database specific. Hence if they
are hard coded in the class you would need to do something about it.

 

[Lew]

In case you are planning to use Properties, you would need to put the
database queries and DML as well in the Properties file. In some
situations the DML and queries can be Database specific. Hence if they
are hard coded in the class you would need to do something about it.

Need to? No. Want to? Maybe, but I doubt it.

How many projects have you ever been on that changed DMBSes?

Why in the world would you use DBMS-specific constructs if you are ever
planning to change DBMSes? Use vanilla SQL and put the tricky stuff in the
Java code.

Consider if you had such a properties file. It could be massive, incredibly
hard to debug, and just as difficult to change as code if you did switch back
ends. The code that used those SQL statements would be segregated from the
logic that it implements and thus much harder to debug and maintain.

If the code is in well-designed DAO-layer classes, then the effort of changing
the SQL is the same if you change back ends, but maintenance and debugging for
the much more usual case of not changing DMBSes is much, much easier. Locality
of reference applies to the mind, not just memory chips and caches.

Keep the SQL with the Java code that uses it, not in a properties file.

-- Lew

 

[ck]

Need to? No. Want to? Maybe, but I doubt it.

How many projects have you ever been on that changed DMBSes?

If that was the situation then this question would have not existed in
the first place.

Why in the world would you use DBMS-specific constructs if you are ever
planning to change DBMSes? Use vanilla SQL and put the tricky stuff in the
Java code.

[Clipped]

May be using properties file is a bad idea but what I wanted to convey
was that -

There are lot of DB specific features, which developer might use to
develop the application(initially), later when you have to migrate to
someother DB its a problem. For that matter Databases don't follow any
standard for DML or Queries, in my opinion Oracle is a leader at
breaking the standards set.

Ck
http://www.gfour.net

 

[Lew]

in my opinion Oracle is a leader at breaking the standards set.

MySQL and MS Access have Oracle way beat.

-- Lew

 

[Guest]

Need to? No. Want to? Maybe, but I doubt it.

How many projects have you ever been on that changed DMBSes?

Ever head about "products" that needs to support many databases.

Why in the world would you use DBMS-specific constructs if you are ever
planning to change DBMSes? Use vanilla SQL and put the tricky stuff in
the Java code.

Sometimes you need database specific features.

Try think about why most persistence frameworks require
you to specific the SQL dialect.

Consider if you had such a properties file. It could be massive,
incredibly hard to debug, and just as difficult to change as code if you
did switch back ends. The code that used those SQL statements would be
segregated from the logic that it implements and thus much harder to
debug and maintain.

You may be right.

But non the less the use of putting critical information in
config files is rather widely used in Java - from EJB's to
Hibernate to Spring.

Arne