Re: Inserting a new obligatory entity in an relation, where? (SOLVED?)
Re: Inserting a new obligatory entity in an relation, where? (SOLVED?)
- Subject: Re: Inserting a new obligatory entity in an relation, where? (SOLVED?)
- From: Johan Henselmans <email@hidden>
- Date: Sat, 21 Apr 2012 11:32:21 +0200
On Apr 17, 2012, at 7:25 PM, Pascal Robert wrote:
>
> Le 2012-04-17 à 13:18, Ramsey Gurley a écrit :
>
>> Agreed. I like George's original suggestion. In the migration that creates the required contract relationship, go through all the existing Shows and create a default contract there. Keep the data clean. Don't use awakeFromFetch for tricks like this.
>
OK, thanks for all the suggestions, it was merely an intellectual exercise, I wuuld neer do such of thing in realty, would I? (Oops, just did it, now I have to remove the code again...
> +1. I have done that a couple of times for the WOCommmunity stuff. But beware, post migration is only done for the last migration, so let's say on your dev db, you are at migration 10 but prod is at migration 8, if your post migration to fix problems is in migration 9, post migration won't happen when migrations 9 and 10 are on in production.
>
I cannot imagine a deployment database that is ahead of the dev database, or am I misunderstanding your remark?
Why would I only do it with the migration that created the contract relationship? I understood you could always get away with it, as long as it is in a migration after the change in the database that requires it.
Suppose you're on migration 6, migration 7 creates the contract relationship, than migration 8 and 9 add something else, after which I decide it would be a dandy idea to add default contracts to each show, what would be the problem to add the default stuff in migration 10? In the deployment, all the migrations would be replayed until they are at the current level, isn't it?
>> Think about it... What if the company hires some J2EE/Ruby/PHP jockey to build an app on the same database? How's it going to look for WO when he complains that WO apps have miserable data integrity? :-)
>>
>> Ramsey
>>
>>
>> On Apr 17, 2012, at 9:45 AM, 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
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Vriendelijke Groeten,
>>>>>>>>>
>>>>>>>>> Johan Henselmans
>>>>>>>>> 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
>>>>>>>>
>>>>>>>> Vriendelijke Groeten,
>>>>>>>>
>>>>>>>> Johan Henselmans
>>>>>>>> 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
>>>>>>
>>>>>
>>>>> Vriendelijke Groeten,
>>>>>
>>>>> Johan Henselmans
>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>> --
>>> 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 (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
>
Vriendelijke Groeten,
Johan Henselmans
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