On Apr 14, 2012, at 10:20 PM, Johan Henselmans wrote:
>
> On Apr 14, 2012, at 4:17 PM, George Domurot wrote:
>
>> In your code snip, you aren't adding the newContract object into the editing
>> context. To reduce errors like these, always use:
>>
>
> Thanks, after I posted the code I noticed that error and added
> eo,insert(newContract)
>
> It still does not want to run.
>
> I suppose there is some faulting going on: I noticed that the
>
> if (contract()==null)
>
> clause did not get triggered while fetching shows that did not have a
> contract.
>
OK, some reading on Faulting in the Enterprise Objects Framework Developers
Guide indeed told me that the relationship contract() would not be null,
because of the faulting behaviour (page 205).
However, asking for an attribute of a relationship would trigger a round trip
to the database and would give me the required error.
After a lot of tinkering (I am a big fan, out of necessity of Wonder Tinkering)
I cam up with the following solution:
public void awakeFromFetch(EOEditingContext eo){
super.awakeFromFetch(eo);
try{
contract().contractDescription();
} catch (Exception e){
Contract newContract = new Contract();
newContract._setValueForPrimaryKey(new
Integer(ShowInfo.this.primaryKey()), "contractId");
eo.insertObject(newContract);
newContract.setContractAmount(new BigDecimal(0.0));
newContract.setContractDescription("empty: fake
Contract");
newContract.setContractRemarks("empty: fake
contract"+this._primaryKey);
newContract.setContractType(ContractTypeEnum.RENT);
eo.saveChanges();
}
}
I tried just creating a new contract, and add that to the show, but that did
not create the proper primary keys (show owns the contract and Propagates the
Primary Key), so some very strange things happened then.
Does anybody see any caveats in creating records that are not there like this?
(apart from the fact that you should not create records in such a way but via
ERMigrations or a perl script or whatever)?
>
>
>> ERXEOControlUtilities.createAndInsertObject
>>
>> I'd recommend not doing this in awakeFromFetch, but making this a step in
>> your migration to clean-up your DB/object graph. 1,500 new objects is a
>> light amount of processing and will keep your model object's code clean.
>>
>> -G
>
> I know that would be a simpler solution, (and propably will do it) but I am
> still curious why the code does not work.
>
>>
>>
>> On Apr 14, 2012, at 1:52 AM, Johan Henselmans wrote:
>>
>>> I am working with shows, that should have contracts.
>>>
>>> That was only discovered after some shows (let's say 1500) had already been
>>> in the database.
>>>
>>> So I created a new entity Contract, that has a not null relation to show,
>>> get's it's primarykey propagated from the show which owns the destination.
>>> If the shows is deleted, the contract is deleted (Cascade), like so:
>>>
>>> <PastedGraphic-9.png>
>>>
>>> <PastedGraphic-8.png>
>>>
>>> I thought that with the code:
>>>
>>> public void awakeFromFetch(EOEditingContext eo){
>>> if (contract()==null){
>>> Contract newContract = new Contract();
>>> newContract.setContractAmount(new BigDecimal(0.0));
>>> newContract.setContractDescription("tempDescription");
>>> newContract.setContractRemarks("tempRemarks");
>>> newContract.setContractType(ContractTypeEnum.RENT);
>>> setContractRelationship(newContract);
>>> eo.saveChanges();
>>> }
>>>
>>> }
>>>
>>> In the extended class of the _Show this would make sure that everything
>>> gets filled, in the case a contract has not been created as it does with
>>> new shows because it is an old show.
>>>
>>> Alas, that does not seem to be the case. What should I do to create a
>>> contract the moment an old show does not have a contract?
>>>
>>>
>>>
>>>
>>> Vriendelijke Groeten,
>>>
>>> Johan Henselmans
>>> jo...@netsense.nl
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/mastermind%40knuckleheads.net
>>>
>>> This email sent to masterm...@knuckleheads.net
>>
>
> Vriendelijke Groeten,
>
> Johan Henselmans
> jo...@netsense.nl
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/johan%40netsense.nl
>
> This email sent to jo...@netsense.nl
Vriendelijke Groeten,
Johan Henselmans
jo...@netsense.nl
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
