> 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.
Given a finite predefined set of "persistent" classes, it shouldn't be that
hard to tell the 2 types of properties apart from each other. Does Isis know
all the classes it will be working with upfront, or is it lazily introspecting
them one at a time as they are accessed by the app?
> class Customer extends CayenneDataObject {
>
> public int getNumber(){...}
>
> public Address getAddress(){...}
>
> }
BTW, take a note of how typical getters/setters are implemented in
CayenneDataObject subclasses (an example from our unit tests). Hope that's ok
in the Isis environment:
* Simple properties:
public void setArtistName(String artistName) {
writeProperty("artistName", artistName);
}
public String getArtistName() {
return (String)readProperty("artistName");
}
* To-one relationships:
public void setToArtist(org.apache.cayenne.testdo.testmap.Artist toArtist) {
setToOneTarget("toArtist", toArtist, true);
}
public org.apache.cayenne.testdo.testmap.Artist getToArtist() {
return
(org.apache.cayenne.testdo.testmap.Artist)readProperty("toArtist");
}
* To-many relationships
public void addToArtistExhibitArray(ArtistExhibit obj) {
addToManyTarget("artistExhibitArray", obj, true);
}
public void removeFromArtistExhibitArray(ArtistExhibit obj) {
removeToManyTarget("artistExhibitArray", obj, true);
}
@SuppressWarnings("unchecked")
public List<ArtistExhibit> getArtistExhibitArray() {
return (List<ArtistExhibit>)readProperty("artistExhibitArray");
}
Andrus
On Dec 9, 2011, at 6:58 AM, Kevin Meyer - KMZ wrote:
> 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
>
>