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

From: Mike Kienenberger (mkienen..mail.com)
Date: Mon May 19 2008 - 11:07:11 EDT

  • Next message: Dirk Lattermann: "SelectQuery and new objects"

    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 <awiesman..omap.org> wrote:
    > On Mon, 19 May 2008 09:19:26 +1000
    > Aristedes Maniatis <ar..sh.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=..ser">
    > <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
    >



    This archive was generated by hypermail 2.0.0 : Mon May 19 2008 - 11:07:42 EDT