On 19 December 2011 20:00, Richardson, Jason - FSA, Kansas City, MO < [email protected]> wrote:
> 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. > ok; in which case Kevin's proposal makes sense. In fact, we ought really to support it in a more general case, as a sort of non-transactional federated object store that defines its own annotation to know where any given domain object is hosted and route to the appropriate underlying object store. > > 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. > In general, I recommend writing a bit of DDL to replace the Isis generated tables with views that map onto your legacy tables. This will give you a useful abstraction layer. Also, you can use instead-of triggers on your views to map to multiple legacy tables if required. > > 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. > Looking into the code, it would seem that that can be specified by a parameter. eg, for a class com.mycompany.Customer, you ought to be able to add (something like) the following to isis.properties: isis.persistor.sql.automapper.default.table.com.mycompany.Customer=tbl_customer Put a break point in AbstractAutoMapper#setUpFieldMappers as a starting point (just before it calls into the getTableNameFromSpecification() method). > > 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. > Let us know how you get on... Dan > > > 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 > >
