SQLDataSource beans

[jpappalardo]

Here is a simple question:

Our server side code uses the following Entity Objects to encapsulate a set of data

That should be sufficient detail to understand where the data model is headed.

Your documentation clearly states that we should prefer SQL over JPA DataSources. It also states that DataSources can return beans.
I have tried at great length to create a pojo that models the server side implementation, and to get an SQLDataSource to effectively return that bean as a DSResponse. Declaring that bean to be a schemaBean however blows up as there is no column in the table with the name cdl, sortie, etc. Declaring that bean using beanClassName results in a successful fetch however the data returned is flat much like the resulting table from using Embeddables. So I thought perhaps I could use valueXPath to define the mapping of fields to bean setters and getters, but then it complains that the returned object has no such objects and methods.

So I am wondering, am I missing something in configuration, or are my expectations not in alignment with what an SQLDataSource can really do? I have poured over the documentation and samples and do not see anything that either confirms or denies this is capable, neither any example that illustrates such an idea. Am I actually expected to use a JPA2DataSource in this implementation? If you would like I can provide all entity and embeddables, along with ds.xml and bean classes. But for expediency at the end of the day, and an expectation that you are going to tell me that this is not possible I will forgo providing them at this moment.

Thanks for you explanation in advance :)

[Isomorphic]

Give the standard List of Maps format returned by DSResponse.getDataList() when you use SQLDataSource, you can populate a nested bean structure by defining a *second* DataSource that has valueXPath declarations that map the flat structure to bean definitions, and using DataSource.setProperties() with that DataSource.

It's unclear whether this would actually be worth doing. Bigger picture, the philosophy behind the SQLDataSource is that you don't write a bean at all, since:

1. the vast majority of entities in the vast majority of applications do not have any business logic that needs to be written where having a dedicated bean would actually help. The most common forms of "business logic" are handled declaratively via validators, Declarative Security settings, request modifiers, etc, and in most of the remaining cases, whatever business logic needs to be implemented is just as easy to write working with Maps.

2. it very very rarely makes sense to pass a nested data structures to the browser. In most cases, if there are related objects the user might view, it makes sense to make a server trip to fetch them, because loading them in advance has poorer performance. So JPA's ability to give you a nested bean structure with lazy loading is mostly a nuisance when delivering data to the browser (or any client) - you don't want to send subobjects most of the time, and the lazy loading feature makes it necessary to be careful when serializing to avoid sending the entire object tree.

Note on #1 - some people are made uneasy by the lack of compiler type checking when writing business logic. It's important to remember that compiler type checking is just another form of automated test. If you have subsystem and application-level automated tests covering the same code, compiler type-checking can become redundant, and compiler type-checking comes at the cost of large amounts of boilerplate Java code with no actual function.

This is not to mention how easy it is to write code with horrifically bad SQL access patterns when working with JPA, and the huge amount of code and redundancy required to get back to the efficiency of straightforward SQL queries and joins..

However ultimately, if you decide you really really want to use a bean abstraction in a particular business logic scenario, SQLDataSource allows and facilitates this, as explained above.

[jpappalardo]

That was insightful thank you