Re: [eclipselink-users] Request for Feedback: EclipseLink in Large RCP A

["Tim Hollosy" <hollosyt@xxxxxxxxx>]

We're using the OSGi proof of concept, it was easy enough to just
check out all the projects from svn. Good to hear we're not crazy,
will report back soon with results.

Thanks,
Tim

On Tue, Apr 1, 2008 at 2:36 PM, Shaun Smith <shaun.smith@xxxxxxxxxx> wrote:
>
>  Hi Tim,
>
>     Great to hear you're making such quick progress!  And your strategy
> sounds fine.  You don't need to worry about the EclipseLink "native"
> configuration or querying unless you need them. Our goal is to get
> everything accessible in a JPA friendly manner.  Are you using the OSGi
> proof of concept code or the eclipselink.jar approach?  I look forward to
> your blogs on this.
>
>    Coincidentally I'm just finishing up an example on using eclipselink.jar
> and persistence.jar in a basic RCP app.  The goal of this is just to show
> the simplest way to add EclipseLink to RCP because a few people seem to be
> trying to do this.
>
>       Shaun
>
>
>
>  Tim Hollosy wrote:
>  After bouncing around the wiki and toplink/eclipselink docs for an
> afternoon and implementing a proof of concept, we've formulated a plan
> for implementing EclipseLink as the database layer. This looks like it
> will work, however we appreciate some feedback in the feasibility of
> this strategy as well any obviously stupid
> assumptions/mistakes/gotchas.
>
> Environment:
> Client: Large J2SE RCP Application
> Database: PostgreSQL databases behind proxy (this handles
> fail-over,connection pooling, auto-commit is ON)
>
> Application Requirements:
> Standard database backed application, using Editors to do most
> inserts/updates this requires detecting a "dirty" (changed) state,
> reverting to original, getting specific differences, etc.
>
> Strategy:
> Use EclipseLink's EntityManager implementation (configured
> programatically) to handle all connections, we're not using
> eclipselink's native sessions (defined by sessions.xml) because we
> didn't care for it's query language vs the pure JPA query language.
>
> Take advantage of the getUnitOfWork() method to leverage UnitOfWork
> methods such as hasChanges(), etc. to handle keeping track of object
> states.
> So we hard-cast like:
>
> ((EntityManagerImpl)em).getUnitOfWork().hasChanges();
>
> Anything that needs to do database work will have it's own "Model"
> implementation consisting of an EntityManager and UOW(s). I won't go
> into detail here about databinding, etc. but we plan on leveraging JPA
> annotations to take some nice shortcuts there.
>
> Once we've got a nice CRUD implemented I'll probably publish the code
> and blog about it since there doesn't seem to be any RCP CRUD examples
> up yet.
>
>
>
>
> --
>
>
>
>  Shaun Smith | Principal Product Manager, TopLink | +1.905.502.3094
>  Oracle Fusion Middleware
>  110 Matheson Boulevard West, Suite 100
>  Mississauga, Ontario, Canada L5R 3P4
>
> _______________________________________________
>  eclipselink-users mailing list
>  eclipselink-users@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/eclipselink-users
>
>



-- 
./tch