Hi Greg, I've done that few times in the past to bring legacy data to mobile apps.
The first question to answer is do you need a write access to these databases? Except if you are replacing an older system, usually, you only read from this data. If you only read, I suggest you build a new database for the unified dataset by adding a "location" or any other attribute to keep a trace of the origin. For your primary keys, you may either use compounds (location + ...) or adding new primary keys attributes. Import-update scripts are easier to write and faster with compound primary key that use the legacy primary key but it may simply be easier to add a clean primary key everywhere if your data set is not too large. Just do not do the import-update with EOF, the fastest way is to load data in a temporary table and issue some insert, update and delete on the complete table. The import-update frequency need to be adjusted to the business needs. For update, you may implement some sort of update request to the legacy system or database. After a batch import, you may invalidate snapshots for these entities to ensure fresh data. BTW, if you want to keep the system isolated, use flat files to transfert data. Samuel Le 2014-02-24 à 08:10, Greg Brown <[email protected]> a écrit : > I have a given database I want to integrate into some existing webobjects > info systems. > > The database is not too normal, so some directions to proceede would be > appreciated. > > Q1. Some tables have no primary key, so no EOs. But there is a method called > rawRowsForSQL on the EOUtilities class. Is that the best option other than > raw sql? All other tables have non-numeric primary keys , columns which > really should be entity attributes and not primary keys. Wonder has > er.extensions.eof.ERXEOAccessUtilities; any other things I should look at for > raw row non-EO fun? raw SQL? > > Q2. There is what I would consider a location attribute, but instead of > making it an attribute, it is used as a database name. So there is one model, > but several databases, all similar except for the connection dictionary. The > dictionaries only differ slightly: > > jdbc:postgresql://localhost:5432/locationA << (At least postgres is > involved.) > VS > jdbc:postgresql://localhost:5432/locationB > > EnterpriseObjects.pdf discusses: > > How does an EOObjectStoreCoordinator determine which of its > EOCooperatingObjectStores should service a particular fetch specification? > Remember that within an EOModelGroup, entity names must be unique. Also > remember that fetch specifications are entity-centric—every fetch > specification is specified on the basis of a particular entity. So an object > store coordinator simply looks for the list of entities registered within its > cooperating object stores to match an entity name to particular cooperating > object store. > > So I need to setup a EOObjectStoreCoordinator (OSC) for each different > database, and change the connection dictionary so it has the correct jdbc url: > > jdbc:postgresql://localhost:5432/locationA << default with model > jdbc:postgresql://localhost:5432/locationB > jdbc:postgresql://localhost:5432/locationC > > On these OSCs, I can use EODatabaseContext.forceConnectionWithModel to set > the correct connection dictionary, or EOUtilities.connectWithModelNamed, or > some other method somebody (not me) knows of. Then I just use ECs from the > correct OSC to do the raw row non-EO fun: > > EOObjectStoreCoordinator locationBObjectStore = new > EOObjectStoreCoordinator(); > EOEditingContext editingContextLocationB = new > EOEditingContext(locationBObjectStore); > > Does this sound like the correct direction to deal with these databases? > > > refs: > Re: Different Database Connection per session for the same model > site:lists.apple.com goat herding > > > What could go wrong? > > Thanks, > > Greg Brown > [email protected] > > > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.com > > This email sent to [email protected] _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
