On 03/27/2013 01:36 PM, Mike Kolesnik wrote:
----- Original Message -----
Hello,
according to my experiences Hibernate/JPA is the best solution for
application
which has to support multiple databases.
+1
JPA would be much easier to maintain than the current approach.
In most cases the stored procedures we use are for CRUD operations,
and can be easily replaced.
The exceptions can be dealt with when necessary, but generally it
seems like an excellent direction to me.
Even when I was part of the
team who
migrated application with business login written in Oracle PL/SQL
procedures
to JBoss using Hibernate (application ran only on Oracle), it became
much easier
to maintain this applications and also customer was pleased that
application
ran much better.
Now imagine the scenario, that for example Postgresql, MySQL, Oracle
and MS SQL would be
supported. I you need to change some stored procedure you should do
this on 4 places using
4 different database dialects.
Like any other technologies, Hibernate/JPA has some drawbacks, but
when it's used properly
and database objects are redesigned to fit Hibernate and portability
needs, it works fine.
I don't think our DB/POJO design is very problematic in this regard..
I think we can replace most of the existing DAOs with ORM backed
implementations with very little work.
What we need to make sure is not break the DAO API.
For example, if I fetch an entity from a Session,
it would reflect any change that happens to it automatically to the DB.
This is not how the current API works, so this feature should be disabled
or otherwise we would have a hard time hunting the bugs that will spawn
from this change of behavior.
This is in my opinion the main disadvantage of using Hibernate (or any
other JPA implementation) with our current architecture. However
Hibernate provides the stateless session concept, which is not standard
but could help.
Martin Perina
----- Original Message -----
From: "Alon Bar-Lev" <alo...@redhat.com>
To: "Juan Hernandez" <jhern...@redhat.com>
Cc: engine-devel@ovirt.org
Sent: Tuesday, March 26, 2013 7:39:16 PM
Subject: Re: [Engine-devel] Move SQL out of stored procedures
----- Original Message -----
From: "Juan Hernandez" <jhern...@redhat.com>
To: engine-devel@ovirt.org
Sent: Tuesday, March 26, 2013 7:34:04 PM
Subject: [Engine-devel] Move SQL out of stored procedures
Hello,
I would like to start a discussion about the subject. I think
this
is
something we need to do if one day we want to be able to use any
database other than PostgreSQL.
Hello,
I think that database layer is a software interface like any other
software interface, if done properly, a dba can convert the stored
procedure to any other database without any code change.
This way the database specific implementation lives within the
database and maintained by the designated dba.
Fixups and optimizations can be done in database without touching
the
code.
Backward compatibility layer is much simpler to implement based on
stored procedures than complex set of views and tables.
Also, accessing the database via different technologies is simpler
if
there is maintained database interface (stored procedures).
I've seen hibernate based java applications that promised to be
database independent but at the edges when performance counts, the
DAO became HQL, then a special dialect and finally database
specific
SQLS.
Regards,
Alon Bar-Lev.
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
