cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Is it possible/easy to integrate cayenne with other frameworks?
Date Sat, 10 Dec 2011 05:37:24 GMT
> 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 
> 
> 


Mime
View raw message