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" <alonbl(a)redhat.com>
>> To: "Juan Hernandez" <jhernand(a)redhat.com>
>> Cc: engine-devel(a)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" <jhernand(a)redhat.com>
>>> To: engine-devel(a)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(a)ovirt.org
>>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)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.