Recommended starting point for SmartGWT-EE persistence.

[JPPoulin]

Hi SmartGWT-EE gurus…

May I obtain your advice on which persistence back-end is recommended as a starting point to accommodate robust server-side database functionality and sophisticated client-side multi-table interactions?

My client-side needs are fairly complex, involving about 7 tables, most of them edited on the client side in a ListGrid, but featuring extensive usage of comboboxes looking up records in other tables. Of course, the whole structure must accommodate cascading updates and deletes, etc.

I have come pretty far with the ‘ds-JPA’ SmartGWTEE starting point sample, but have come into several issues I just don’t know how to overcome. As I don’t have the source code for the JPA functionality inside SmartGWT-EE, I’m progressing with a blackbox and as I’m not a JPA expert, development has been very difficult and frustrating.

(I am considering restarting with the ‘ds-hibernate’ starting point.

Four questions:
1. Which of the persistence engine is best supported / most tested with SmartGWT EE for complex database interactivity on the client-side?

2. Between the ‘ds-hibernate’, ‘spring-hibernate-dmi’, ‘ds-jpa’ and some of the approaches in ‘showcase’, which is the recommended starting point?

3. Which of the samples is most ‘open’? (e.g. I can debug through the source code when I get in trouble)

4. If you were starting a large database project requiring sophisticated client-side interaction, where would you begin? (e.g. what sample, tutorial, documentation would you read?)

Many thanks for any hint in the right direction!!

Jean-Pierre

[Isomorphic]

As the QuickStart says, we recommend the SQL DataSource as the most flexible, fastest, most easily customized option. JPA and Hibernate interpose additional layers creating complexity we can't completely simplify away. The QuickStart Guide is alsothe best overview for the capabilities of the SQL DataSource.

[JPPoulin]

Hi Administrator, thanks for that recommendation.

In this case however, the capacity of SmartGWT EE to talk to javabeans containing sophisticate business logic while being backed up to a database in a highly granular fashion is required functionality... hence the need for a ORM engine such as Hibernate or JPA+Hibernate, or Hibernate+Spring.

Assuming an ORM is a must, which of these is the most robust starting point to build upon?

Thanks again for taking the time!

Jean-Pierre

[atomatom]

I had a fair bit of pain debugging the server DB code as well - complicated by JPA running on AppEngine.

In the end, I wrote my own code and use the SmartGWTEE DMI methods. It is certainly more work than the nice examples, but I have control over the server methods so I can see what is going on. If you are having trouble figuring out what is going on, you could create a DMI method and use to debug things; you can always point it back to the isomorphic handler once you figure out what is going wrong.

[Isomorphic]

That's not a set of requirements that implies ORM - it's a set of requirements that we routinely fulfill with SQLDataSource with much less effort.

Grab a book on JPA best practices and you'll see Spring services added on top of JPA as a best practice. This is because JPA doesn't really encapsulate anything at the bean level; most of the operations you want to encapsulate are a transactional operation across *multiple beans*. Typical JPA beans are just a bunch of setters and getters (the "anemic domain model" problem).

So SQLDataSource + DMI is the same architecture, except it doesn't force you to write empty beans and other boilerplate code and has much greater transparency with respect to how SQL is generated and how you can customize it. That's why we recommend it. Fuller explanation and other benefits explained here.

If you are forced by pre-existing code to choose between JPA and Hibernate, you're choosing between an official standard API (JPA) with significantly less functionality (no direct SQL, less persistence modes, etc) vs specifically using Hibernate when eg DataNucleus might be useful in another context. There is no particular difference in robustness in the SmartGWT connectors to these APIs. If you have trouble, ask specific questions.

[Isomorphic]

Just to note: so far as we know, atomatom's experiences are limited specifically to JPA and GAE (Google App Engine). Our JPA connector is necessarily less functional and limited on GAE because GAE's JPA implementation is limited (it's based on BigTable). GAE also has a tendency to report errors poorly when you use JPA in ways that are typical for JPA but won't work for GAE's BigTable implementation.

atomatom, we'd appreciate it if you could make it clear that your experiences come from this very unusual case if you're going to give advice to other users.

[JPPoulin]

Hi Administrator,

Thanks for that feedback. Perhaps ORM is not absolutely required.

Here are the ‘must have’ for this project… which will contain about a 10 important tables coupled to another 20 or so lookup tables for the combobox fields.
- SmartGWT-EE is the only ‘client’ for this database… so we need it to basically do everything for different user types.
- The business logic on the server needs to programmatically insert entries and update the database regularly. However, it won’t require to have many objects loaded in memory… most can stay in the database.
- Many of the actions users take as they manipulate database entries invokes actions on the server, such as placing a telephone call or sending an email.
- We need full cascade updates & deletes working.

Just to make sure I’ve read you right… You mention these requirements can be handled by SQLDataSource with much less effort without ORM, yet you recommend using JPA+Spring which implies ORM…

I’m hoping to construct a highly robust database that will work flawlessly over SmartGWT-EE without requiring a rocket science degree every time I insert a new join. I could spend a couple weeks learning JPA or Hibernate, but based on the troubles I’ve been having trying to get simple things like comboboxes to work correctly with JPA with just 6 tables thus far, I’m a bit afraid that I’ll eventually paint myself in a corner attempting to get SmartGWT-EE & ORM working well together to edit a fairly complex database.

Based on the above requirements, do you recommend to ditch ORM by re-starting the project based on the SQLDataSource sample, or is a renewed effort of JPA+Spring the best approach?

Thanks again for taking the time.

Jean-Pierre

[JPPoulin]

Hi atomatom,

Thanks for the reply. Much of the trouble is indeed caused by having a 'blackbox' between the highly complex SmartGWT client and the also complex JPA & Hibernate. Not having the source code for the JPA SmartGWTEE adaptor slows development to a crawl everytime your run into unexpected behavior.

I also toyed with DMI in the hibernate sample with some modifications I could know what is happening, but I ditched it when I found the jpa sample with the nice adaptor, thinking they'd do a better job than I could anyways, but the opacity brings problems all of its own!

I'll be rescanning all the SmartGWTEE samples to re-evaluate which is the most open and usable platform to build upon.

Jean-Pierre

[Isomorphic]

Just to make sure I’ve read you right… You mention these requirements can be handled by SQLDataSource with much less effort without ORM, yet you recommend using JPA+Spring which implies ORM…

No, you have it completely backward - we're telling you that the architectural goals of JPA and Spring are met by SQLDataSource+DMI with far less effort.

As far as problems with "opacity" - given where you are (just learning these ORM systems), and since you've never asked any concrete questions or discussed any of the specifics of the problems you're having, it's far too early for you to be blaming any particular component for difficulties.

Regardless, the first step is following SmartGWT's best practices (SQLDataSource). As we tell you in the QuickStart Guide, this is what's recommend unless you have a large pre-existing investment in JPA, Hibernate or some other ORM system. If you're just *learning* those systems, that's all the more reason to go with the best practices rather than override them!

[JPPoulin]

Hi Administrator,

Ok, I understand your post more clearly. I'm totally hoping to follow best practice as recommended by the expert as the #1 dependency here is SmartGWT-EE and all the other dependencies chosen to create a system that is as robust and simple as possible. I'm hoping to avoid learning ORM unless it really brings great value to the project, and thus far it appears to be far too much trouble for this many tables.

I'm particularly concerned about the poor performance multi-table accesses give when using JPA (as per your link) and I already do very well with SQL.

Which of the SmartGWT-EE samples do you think is the closest fit to our requirements?
- built-in-ds: for straight SQL access.
- ds-dmi: for parts of database that need access to in-memory beans/
- custom-ds: for Spring MVC controller
- some parts of 'showcase'?

Thanks again!!

Jean-Pierre

[Isomorphic]

All the samples under the "SQL" folder, and ignore anything under Hibernate/JPA etc. But first and foremost: a cover to cover read of the QuickStart Guide, focusing on the Server Framework chapter.

Spring is another system to introduce only if you understand it well and have a clear idea of what problem you're trying to solve with it, otherwise, no need.

[JPPoulin]

Hi Admin,

Thanks again, I'll do exactly that... a thorough read of the quick start guide followed by a review of all samples in SQL folder of showcase, followed by a detailed review of built-in-ds samples.

Thanks again and have a great day!

Jean-Pierre

[atomatom]

for sure, i did qualify my experiences, and only meant to give an idea on how i managed to track down my issues; i did not mean to add to your support load.