My project uses 2 databases one sql server and db2. There aren't any combined transactionality requirements. For example 1 domain object will consist of data from 1 sql server table or a combination of several sql server tables. They will be separate domain objects than the DB2 objects. In the very very far future I may put in an object that contains data from both databases. However it is out of scope at this time.
Additionally, is there an easier way to get around the "ISIS_<object>" table name functionalty, since I'm using legacy databases? I checked into the "getTableNameFromSpecification" in the AbstractAutoMapper and I don't see that method on the class. I'm using the 1.2 snapshot from maven1. It would be best if there was a property that I could set to not use the "ISIS_" prefix. I think this would be a great benefit to isis as I think a lot of applications will be using predefined database names and database fields. The Architecture office isn't really big on adding framework/technology information into the database names. Due to my legacy table restrictions, here is the convention I was planning on using. Isis DOM Class Name = Existing DB Table Name Isis Dom Field Name = Existing DB Column Name Again, thanks for all of your assistance. Jason Richardson -----Original Message----- From: Dan Haywood [mailto:[email protected]] Sent: Monday, December 19, 2011 1:45 PM To: [email protected] Subject: Re: Questions regarding the quickstart app and creating a Proof of Concept On 19 December 2011 18:28, Kevin Meyer - KMZ <[email protected]> wrote: > > > Thinking about your need to access two databases simultaneously - I > have already implemented something that I required for another > project that built a custom datastore that farmed off requests to one of > two destinations based on (in my case), a single class type. > > That might be the quickest solution ... Before going too far down this route, can I ask about transactionality requirements? ie are there any? If so, then it might be better to leverage an OpenJPA-based object store, since OpenJPA supports distributed persistence already. Dan
