On 19 Dec 2011 at 20:00, Richardson, Jason - FSA, Kansas City, MO 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.
That's great. > 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. We'll need to test for the behaviour I am worried about, to see if it is a problem or not. > 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. How often are the snapshots updated? Dan? Jason, I'd suggest grabbing the latest version of the framework via subversion. You're asking for some changes that might take time to make it to the repositories. > 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. Understandable. > > Due to my legacy table restrictions, here is the convention I was planning on > using. > > Isis DOM Class Name = Existing DB Table Name At the moment, this can't be changed. The quickest change would be to make the "ISIS_" prefix configurable from the properties file, where you could set it to nothing. Wonder if that'll work... Jira ticket: ISIS-160 [1] > Isis Dom Field Name = Existing DB Column Name This should work already, except for collections handling. I don't know how your existing collections (1 to many, many to many) relationships are currently mapped... At the moment, an entity property is mapped with FK_+property name, and stores the Oid of the referenced entity. Collections use a combination of FK_ + property name + class name. If this doesn't work for you, perhaps you can get away with marking them at @NotPersisted, and manually rebuilding the relationships in your objectstore service (using allInstances(Pattern) searches).... Standard value types are stored as is, except that case changes get an underscore (e.g. CustomerName maps onto customer_name). Since you're talking about several tables needed to be renamed (and possibly some properties), perhaps its time to consider supporting some annotations (or Facets, I suppose, in the Isis context) instead of pushing all this into the properties file. Regards, Kevin [1] https://issues.apache.org/jira/browse/ISIS-160 > > > 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
