I feel the same ..... but he can try it, test it and see what happens I guess.
If it was me, I would have just written a script to migrate the database and be
done with it.
On Apr 17, 2012, at 12:45 PM, Chuck Hill wrote:
> 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
>>>>>>>>> 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/rgurley%40smarthealth.com
>>>>>
>>>>> This email sent to rgur...@smarthealth.com
>>>>
>>>
>>> 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/kelleherk%40gmail.com
>>>
>>> This email sent to kelleh...@gmail.com
>>
>> _______________________________________________
>> 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/chill%40global-village.net
>>
>> This email sent to ch...@global-village.net
>
> --
> 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
>
>
>
>
>
>
>
>
_______________________________________________
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
