Re: Multiple databases and migrations causing weird side affect
Re: Multiple databases and migrations causing weird side affect
- Subject: Re: Multiple databases and migrations causing weird side affect
- From: Joe Little <email@hidden>
- Date: Wed, 4 Aug 2010 17:14:46 -0700
Thanks. I think my problem is more fundamental now since it can't find
any existing entities relative to the second defined database and
model. This has working for me in other other cases, but I'm wondering
if having both models depending on ERAttachment somehow disallows the
secondary database connection, or something similar. I'm simply not
connecting at all to one of my DBs.
On Wed, Aug 4, 2010 at 5:08 PM, Ramsey Lee Gurley <email@hidden> wrote:
> A possibly helpful email from May 6 on the wonder list:
>
>> Hi Ricardo,
>>
>> I'm usually adding the relationships programatically in such situations.
>>
>> E.g.
>>
>> ERXEOAccessUtilities.createRelationship(
>> "contactModifier", // name
>> PDBUUser.ENTITY_NAME, "id", // from
>> PDCrmContact.ENTITY_NAME, "modifiedByID", // to
>> true, // toMany
>> EOEntityClassDescription.DeleteRuleDeny,
>> false, // mandatory
>> false, // class property
>> false // propagate PK
>> );
>>
>> Another more complex example:
>>
>> private void setupDynamicRelationships() {
>> String ownerEntityName =
>> ERXProperties.stringForKey(PROPERTY_OWNER_ENTITY_NAME);
>> if (ownerEntityName == null || "".equals(ownerEntityName)) {
>> log.warn(PROPERTY_OWNER_ENTITY_NAME + " is not set, not setting up
>> owner support!");
>> } else {
>> EOEntity ownerEntity =
>> ERXEOAccessUtilities.entityNamed(ERXEC.newEditingContext(),
>> ownerEntityName);
>> @SuppressWarnings("unchecked")
>> NSArray<String> primaryKeyAttributeNames =
>> ownerEntity.primaryKeyAttributeNames();
>> if (primaryKeyAttributeNames.count() > 1)
>> throw new RuntimeException("Composite primary keys are unsupported");
>> String ownerEntityPrimaryKeyAttributeName =
>> primaryKeyAttributeNames.lastObject();
>> ERXEOAccessUtilities.createRelationship(
>> "owner",
>> PDIBArticle.ENTITY_NAME, "ownerID",
>> ownerEntityName, ownerEntityPrimaryKeyAttributeName,
>> false, EOClassDescription.DeleteRuleNullify, false, true, false);
>> ERXEOAccessUtilities.createRelationship(
>> "articles",
>> ownerEntityName, ownerEntityPrimaryKeyAttributeName,
>> PDIBArticle.ENTITY_NAME, "ownerID",
>> true, EOClassDescription.DeleteRuleCascade, false, true, false);
>> }
>> }
>>
>> For frameworks, I execute that in the framework principal. See
>> ERXFrameworkPrincipal#finishInitialization().
>> For applications, in the Application class
>> (ERXapplication#didFinishLaunching() or finishInitialization()).
>>
>> Timo
>
> Am 07.05.2010 um 01:51 schrieb Ricardo J. Parada:
>
>> Framework A has an entity named 'A'.
>> Framework B has an entity named 'B'
>>
>> I need to setup a to-one named toB which takes me from A-->B.
>>
>> The only catch is that I don't want to introduce a dependency on
>> framework B in my application or framework A.
>>
>> If my application links against framework A only then Wonder throws
>> an exception at startup, which is a good thing. :-)
>>
>> But I do need to join from A to B somehow and keep these frameworks
>> independent of each other.
>>
>> Has anyone done this?
>>
>> I created a SimpleB entity that maps to the same table as B. Then
>> setup A-->SimpleB. That works... but I'm wondering if there's a
>> better way. Like defining SimpleB in a core framework and then have
>> B entity extend SimpleB or something like that.
>>
>> Thanks,
>> Ricardo
>
>
>
>
>
> On Aug 4, 2010, at 7:57 PM, Joe Little wrote:
>
>> I'm on to something here. When I remove the relation and try to run,
>> this application is simply not fetching the model and loading it for
>> admitarch as defined in the Properties files below. Is that normal?
>>
>> On Wed, Aug 4, 2010 at 4:41 PM, Joe Little <email@hidden> wrote:
>>> I have two databases, and two models with their own migrations
>>> pointing at each. When I kick off an application tied to database and
>>> model "B", the migration kicks off with a fresh db as expected.
>>> However, since one relation exists in B to an entity in A, it would
>>> appear that migrations are kicking off to generate the model tables
>>> for both A and B in Database B. Thus, after migrations, but code is
>>> searching against empty tables generated in B for data in that was in
>>> A.
>>>
>>> I hope you followed along with the bouncing ball. It took a while to
>>> see that the model was migrating these duplicate but empty tables into
>>> db B. My Properties file only makes mention of migration models for B,
>>> but I'm presuming that some dependency is being kicked off incorrectly
>>> to cause this. Anyway to force a migration not to happen?
>>>
>>> Here's an example from my dev machine and DBs. I have to define the
>>> global for ERAttachment to work, and both Models A and B do have
>>> references to ERAttachment.
>>>
>>> dbConnectURLGLOBAL=jdbc:postgresql://localhost/gradoffice
>>> dbConnectUserGLOBAL=postgres
>>> dbConnectPasswordGLOBAL=
>>> dbConnectPluginGLOBAL=PostgresqlPlugIn
>>> dbConnectDriverGLOBAL=org.postgresql.Driver
>>> dbConnectJDBCInfoGlobal=
>>>
>>> gradoffice.URL=jdbc:postgresql://localhost/gradoffice
>>> gradoffice.DBUser = postgres
>>> gradoffice.DBPassword =
>>> gradoffice.DBDriver = org.postgresql.Driver
>>> gradoffice.DBPlugin = PostgresqlPlugIn
>>> gradoffice.DBJDBCInfo =
>>>
>>>
>>> admitarch.URL = jdbc:postgresql://localhost/admit-archive
>>> admitarch.DBUser = postgres
>>> admitarch.DBPassword =
>>> admitarch.DBDriver = org.postgresql.Driver
>>> admitarch.DBPlugin = PostgresqlPlugIn
>>> admitarch.DBJDBCInfo =
>>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden