Hi Andrus,
Thanks for the details.
I had an initial read through of the cayenne-guide-08302011.pdf, but
I'm not sure what I'm looking for.
For the most part, I *do* assume that I have total control over the DB,
with no legacy support. Or at least, nothing beyond choosing property
names to suit matching database table column names and similar.
I still don't have a good idea how Cayenne works - how it's started, etc.
More reading required.
At some point, I am supposing I'll want to know: How do I specify that
property X of class Y represents a value (e.g. int), and that property A
represents an instance of class Z.
e.g. (where there's a get, assume there's a set)
class Customer extends CayenneDataObject {
public int getNumber(){...}
public Address getAddress(){...}
}
The Isis internals introspects Customer and creates various classes
that either represent the *definition* of Customer, or provide access to
an actual instance.
The object store uses this information to support creating tables and
mappers (either value mappers or reference mappers).
This is where I expect to I need to tell Cayenne what user domain
objects exist (and need to be persisted), what value properties they
have, and what reference properties (pointing to other user domain
objects).
The subtleties may come into handling polymorphism, etc., but I've
gone through this exercise with Isis.
I've been given a heads-up on how to create a new runtime context for
Isis that will use Cayenne - when I get to the point that I need to persist
an object, that's when I need to know more about setting up Cayenne
programmatically.
Regards,
Kevin
On 8 Dec 2011 at 16:18, Andrus Adamchik wrote:
> Hi Kevin,
>
> I should say that Cayenne is uniquely suited for creating persistent
> stack and mapping at runtime, as there's no class enhancement
> involved. POJO's being subclasses of CayenneDataObject, with set/get
> implemented the way we do them in Cayenne is the only hard
> requirement. From there, as John has mentioned, you make some
> assumptions. The biggest assumption is that you control the DB and
> there's no chance of a legacy schema that you'd have to support...
>
> Implementation (assuming Cayenne 3.1) may be encapsulated in a
> custom Cayenne DI module. We are still in the process of writing the
> docs for 3.1, but most DI features are well documented in this
> otherwise empty PDF:
>
> http://people.apache.org/~aadamchik/misc/cayenne-guide-08302011.pdf
>
> In the custom module define DataDomain loading services to
> reverse-engineer the POJOs instead of loading mapping from XML. This
> is the biggest task, requiring some understanding of Cayenne APIs.
> Feel free to ask here if you get stuck with anything. Also map
> SchemaUpdateStrategy to CreateIfNoSchemaStrategy that will create a
> DB schema based on your mapping.
>
> This should be it at the high level, but of course you'll need to
> write some code here. I used to implement a similar task - going
> from reverse-engineered DB to a runtime mapping of generic Java
> classes, and that worked pretty well.
>
> Good luck, and let us know how this works - maybe some of these new
> factories that you develop could be of general use to Cayenne users
> as well as ISIS users.
>
> Andrus
