IMHO, whether we go ahead with JPA or not depend on the developers (we) who gonna use it. If it's not gonna make our life easier then I am +1 for this.
You only have to change DAO layer from org.wso2.carbon.rssmanager.core.dao.util.EntityManager.java to bottom. It would be great if we can do a background study about all the RDBMs types and how the queries should change accordingly. Cheers, Dhanuka *Dhanuka Ranasinghe* Senior Software Engineer WSO2 Inc. ; http://wso2.com lean . enterprise . middleware phone : +94 715381915 On Wed, Oct 15, 2014 at 6:04 AM, Prabath Abeysekera <praba...@wso2.com> wrote: > I do understand that we'd already spent considerable amount of time > rewriting the DAO layers implemented as part of RSS Manager to use JPA. > However, some of the inconsistencies/issues observed in JPA provider > implementations such as OpenJPA, etc got me thinking we should probably try > to make things simpler particularly, since all of these database logics > could be implemented in an ANSII compliant and vendor-neutral manner using > native SQL. Then again, one might wonder why we don't opt to go get the JPA > related issues fixed/use some stable JPA library to get over the said > issues. That's obviously going be a little complicated as we might probably > depend on some third party library acting as the JPA provider, the control > of which is out of our hands. Therefore, this effort is primarily aimed at > making things simpler and maintainable without getting ourselves dependent > on any third party library for persisting entities manipulated as part of > the respective DAO layers. > > I'm +1 for this. > > Cheers, > Prabath > > On Wed, Oct 15, 2014 at 2:37 PM, Harsha Kumara <hars...@wso2.com> wrote: > >> Hi, >> >> I'm looking through the feasibility and complexity of migrating rss >> manager data access from JPA to native SQL. This is due to inconsistencies >> cause by the JPA in the rss manager core. >> >> With the JPA most of the internal data access APIs use object mode to >> perform CRUD operations. >> With the migrations we will needs to change some APIs and and redesigns >> things as there is no such a object model with native SQL. Also internal >> data service access methods also take the benefit of the JPA object model >> during the persistence. Most of the current APIs design in the way that >> suits for the persistence. With the native all the persistence activities >> will needs to be written with the SQL. Internal restructure will be needed >> with the migration. >> >> @Prabath and Dhanuka WDYT? >> >> Appreciate any suggestions and thoughts on this. >> >> Thanks, >> Harsha >> >> -- >> Harsha Kumara >> Software Engineer, WSO2 Inc. >> Mobile: +94775505618 >> Blog:harshcreationz.blogspot.com >> > > > > -- > Prabath Abeysekara > Associate Technical Lead, Data TG. > WSO2 Inc. > Email: praba...@wso2.com > Mobile: +94774171471 >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
