Doing all this in awakeFromFetch makes me feel kind of nervous. Chuck
On 2012-04-17, at 9:41 AM, Kieran Kelleher wrote:
> Try refaulting the Show after you create the Contract to see if that helps.
> ec.refaultObject(...)
>
> On Apr 17, 2012, at 5:40 AM, Johan Henselmans wrote:
>
>>
>> On Apr 16, 2012, at 6:16 PM, Ramsey Gurley wrote:
>>
>>>
>>> On Apr 16, 2012, at 9:13 AM, Johann Werner wrote:
>>>
>>>>
>>>> Am 16.04.2012 um 16:43 schrieb Johan Henselmans:
>>>>
>>>>>
>>>>> 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 think here you should be careful saving an editing context you don't
>>>> know what else has been changed in. It would be safer to create a new
>>>> editing context, make a localInstanceIn() and save it there.
>>>
>>> I was about to say the same thing. Think about what happens if you're half
>>> way through a wizard page when those things get fetched. It's going to try
>>> to save the changes to the ec and throw a validation exception.
>>>
>>
>> Thanks for the comments. For me here the confusion sets in.
>>
>> We havei ECShow, which contains the Show. It might contain other stuff that
>> is not saved, so if we add Contract to ECSnow and tell save, then the other
>> stuff gets saved too (or not, throwing an exception), which you both
>> corretly pointed out.
>>
>> So we create a new EC, ECContract, in which we create a local instance of
>> Show, then add the contract, and be done with it.
>>
>> Now, however, the fetch in ECShow goes on, knows nothing about Show having a
>> Contract, and throws up, because every Show should have a Contract,
>>
>> Am I correct in my reasoning?
>>
>> So my question is: how do I get the Show in ECShow to acknowledge there is a
>> contract available?
>>
>> Or am I completely missing the point?
>>
>>
>>>>
>>>>> }
>>>>> }
>>>>>
>>>>> 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
>>>>>>>> [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/mastermind%40knuckleheads.net
>>>>>>>>
>>>>>>>> This email sent to [email protected]
>>>>>>>
>>>>>>
>>>>>> Vriendelijke Groeten,
>>>>>>
>>>>>> Johan Henselmans
>>>>>> [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/johan%40netsense.nl
>>>>>>
>>>>>> This email sent to [email protected]
>>>>>
>>>>> Vriendelijke Groeten,
>>>>>
>>>>> Johan Henselmans
>>>>> [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/rgurley%40smarthealth.com
>>>>
>>>> This email sent to [email protected]
>>>
>>
>> Vriendelijke Groeten,
>>
>> Johan Henselmans
>> [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/kelleherk%40gmail.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/chill%40global-village.net
>
> This email sent to [email protected]
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall
knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/gvc/practical_webobjects
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
