crudify and JPA

32 views
Skip to first unread message

Tim Pigden

unread,
Oct 18, 2011, 11:54:28 AM10/18/11
to Lift
Hi
I want to get a basic CRUD application up and running. I want to use
JPA because it's using the same database as a java app which is using
JPA and I figure that would give me some synergy.
However, I want to get up and running quickly which suggests I should
use Crudify.
So the question is, what's the best way to get there?
Should I just go straight with the JPA and ignore Crudify or build an
app using Mapper and then switch the ORM stuff by refactoring my
persistence classes?
Tim

reuben doetsch

unread,
Oct 18, 2011, 12:02:31 PM10/18/11
to lif...@googlegroups.com
Depends on the size of the JPA database. I would switch over to squeryl record, since if you want to switch out the database layer later this is possible. If a very large JPA class with lots of named queries then this is cost prohibative, and so I say just start creating in JPA. 

Reuben

CTO Sportaneous.com


--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

Tim Pigden

unread,
Oct 18, 2011, 12:09:45 PM10/18/11
to lif...@googlegroups.com
Thanks Reuben - yet another choice! Database is not particularly
large. But does use of squeryl still preclude crudify or is
mapper->record refactoring more straight-forward.
Tim

--
Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in
England and Wales.
Company Registration No. 2327613 Registered Offices: Orland House,
Mead Lane, Hertford, SG13 7AT England
This email and any attachments to it may be confidential and are
intended solely for the use of the individual to whom it is addressed.
Any views or opinions expressed are solely those of the author and do
not necessarily represent those of Optrak Distribution Software Ltd.
If you are not the intended recipient of this email, you must neither
take any action based upon its contents, nor copy or show it to
anyone. Please contact the sender if you believe you have received
this email in error.

reuben doetsch

unread,
Oct 18, 2011, 12:15:14 PM10/18/11
to lif...@googlegroups.com
Squeryl is the "record" implementation for SQL. So Record is a agnostic framework that only assumes entities be placed in a "record". This means one can use Mongo, Couch, SQL etc... 

Squeryl Record does have crudify as of the last few months. You can also create easy forms using wizard/lift screen and adding all the fields from the record into the screen.

Reuben

earthling_paul

unread,
Oct 18, 2011, 3:23:40 PM10/18/11
to Lift
Hi Tim,

I do not have specific experience with Mapper/Record and the CRUDify
Trait, so I can't give you advice on that.
However, allow me to be "a bit nerdy" about this sentence

"I want to use JPA because it's using *the same database* as a java
app which is using
JPA and I figure that would give me some synergy"

in your posting, which could be understood in the following ways:


1)
Do you mean by *the same database* the same instance of this database?
So that would mean you have
A) an existing myJPAApp which is accessing myDBinstance
B) a new myLiftJPAApp which is accessing myDBinstance
With such a concurent access you could run into problems, since each
JPA EntityManager likes to to have "exclusive access" on the DB
instance. If that is the case you would face this issue even if you
choose Mapper/Record for the new Lift App, because myJPAApp would
complain.

2)
If you have more of a migration scenario that is myLiftJPAApp is a
successor of myJPAApp, reusing the JPA Layer and using Lift
(Templates, Snippets, SiteMap,...) to build the webapp in an CRUD
fashion you'd be pretty fast.
We do this in our commercial Lift apps although none of them is really
(just) CRUD. IMHO webapps with advanced functionality (beyond CRUD) is
THE use case for Lift and this is where the framework really shines!
Since I have never come accross a "100% CRUD only webapp" in
production (they are all a bit special somewhere, aren't they) such an
approach would give you flexibility for later enhancements.

May the gods of CRUD help you with your decision ;-)
Paul
Reply all
Reply to author
Forward
0 new messages