QueryTable / Non-persisted DataObject [Was: Questions about Ordering, Optimistic Locking and QueryTable]

[Mike Kienenberger <mk...@gmail.com>]

I'm not really sure why you don't use a regular java bean object to do this.

However, I believe you could create a DataMap for all of these objects
in a separate DataNode.   You don't have to create a table for them in
the database.

You might even be able to get away with having them in the same
DataMap, provided you don't try to update/insert/delete them during a
commit.   There's no requirement that you create an actual table on
the database unless you execute sql accessing that table.

On 5/19/08, Adrian Wiesmann <aw...@somap.org> wrote:
> On Mon, 19 May 2008 09:19:26 +1000
>  Aristedes Maniatis <ar...@ish.com.au> wrote:
>
>  > There should be something coming soon with inheritance, but there were
>  > no plans to support persistent objects with no database backing at
>  > all. There is going to be the opposite concept: abstract classes which
>  > have a database table, but which can only be constructed in their
>  > subclass.
>  >
>  > Tell us more about why it would be useful to have data objects which
>  > cannot be persisted to the database.
>
>
> I guess my usage scenario is very specific to my environment. But let me
>  introduce my environment and let you decide.
>
>  I have written a UI renderer and data binding engine (Gozer). For that
>  engine to work I introduced the Domain Model, Table Module and Record Set
>  patterns and DataObjectKeys to Cayenne (at least to some extent). I did so
>  with my own code generator which generates datarows, datarowkeys and table
>  modules to every ObjEntity modeled with the Cayenne modeler.
>
>  For the data binding I use then these table modules. Let's say I have a
>  table with users. I can then bind that table to the UI like that:
>
>  <list databinding="@user">
>    <list_field databinding="username" />
>  </list>
>
>  My UI engine is interpreting the binding information so that the UI
>  renders a list of users with the only field in the list containing the
>  username.
>
>  Which means that whenever I display data on the UI, I am using the same
>  databinding which makes use of my datatable and datarow objects.
>
>  Now to the QueryTable problem: Many applications have some form of user
>  input where a user can enter search criteria and then use that criteria to
>  filter a list of records or search data in the database. Since my UI
>  engine knows how to render my table modules and datarows, I would love to
>  use the same mechanism for query interfaces (a huge time saver).
>
>  To extend my example from above: I could introduce a UserQueryTable with a
>  field UserName. I could then define a view which binds that table. The
>  user enters a username and when clicking on the search button I could read
>  the content from the UserQueryTable and construct the query from the
>  content of that table. Side effect, all my queries would be
>  "standardised" and whenever I need to search for users in my application
>  I can use the same interface (UserQueryTable) which is then sent to the
>  UserQuery Business Object which handles the querying in a central
>  location (domain model pattern).
>
>  Of course I could solve that problem in creating ObjEntity which have
>  a corresponding table in the database (which is never used). But I find
>  this to be very ugly...
>
>  Hope this explained my scenario.
>
>  Cheers,
>
> Adrian
>

Re: QueryTable / Non-persisted DataObject [Was: Questions about Ordering, Optimistic Locking and QueryTable]

[Mike Kienenberger <mk...@gmail.com>]

Well, the other thing you can do is work with Interfaces everywhere,
then create POJO classes implementing your interface for non-persisted
objects.   Don't know if that works any better for your particular
situation, though.

I've done this for a project with Cayenne, and I created cgen
templates to automatically create the interfaces as well as the
concrete Cayenne DataObject classes.  I also created POJO objects for
unit testing and data transfer objects using cgen templates.  The only
trick was handling reverse relationship setting in the base class of
the POJO objects, but it was doable.

On 5/20/08, Adrian Wiesmann <aw...@somap.org> wrote:
> On Mon, 19 May 2008 11:07:11 -0400
>  "Mike Kienenberger" <mk...@gmail.com> wrote:
>
>  > I'm not really sure why you don't use a regular java bean object to do
>  > this.
>
>
> Because of the base class. I don't want to have my renderer check the
>  class to decide how to handle it. What I could try would be to subclass
>  from DataObject without having any info in the DataMap. Not sure how
>  Cayenne would like that though.
>
>
>
>  > However, I believe you could create a DataMap for all of these objects
>  > in a separate DataNode.   You don't have to create a table for them in
>  > the database.
>
>
> That could be a solution. Ugly, but still working.
>
>
>
>  > You might even be able to get away with having them in the same
>  > DataMap, provided you don't try to update/insert/delete them during a
>  > commit.   There's no requirement that you create an actual table on
>  > the database unless you execute sql accessing that table.
>
>
> Yes, I thought something like that. But still an ugly solution...
>
>  Cheers,
>
> Adrian
>

Re: QueryTable / Non-persisted DataObject [Was: Questions about Ordering, Optimistic Locking and QueryTable]

[Adrian Wiesmann <aw...@somap.org>]

On Mon, 19 May 2008 11:07:11 -0400
"Mike Kienenberger" <mk...@gmail.com> wrote:

> I'm not really sure why you don't use a regular java bean object to do
> this.

Because of the base class. I don't want to have my renderer check the
class to decide how to handle it. What I could try would be to subclass
from DataObject without having any info in the DataMap. Not sure how
Cayenne would like that though.


> However, I believe you could create a DataMap for all of these objects
> in a separate DataNode.   You don't have to create a table for them in
> the database.

That could be a solution. Ugly, but still working.


> You might even be able to get away with having them in the same
> DataMap, provided you don't try to update/insert/delete them during a
> commit.   There's no requirement that you create an actual table on
> the database unless you execute sql accessing that table.

Yes, I thought something like that. But still an ugly solution...

Cheers,
Adrian