cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Kienenberger" <>
Subject QueryTable / Non-persisted DataObject [Was: Questions about Ordering, Optimistic Locking and QueryTable]
Date Mon, 19 May 2008 15:07:11 GMT
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 <> wrote:
> On Mon, 19 May 2008 09:19:26 +1000
>  Aristedes Maniatis <> 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

View raw message