I merged the fix to the master and integration branches. As far as I can tell, 
I've got everything done except pushing the tag on master. It just wasn't in my 
push configuration. I can try again when I get home tonight.

As for releasing other integration changes, I tend to use eGit for everything. 
Is there anything in that command line magic which wouldn't happen if I just 
make a local branch at a9426 and merged that into master?

Ramsey

On Apr 1, 2013, at 9:44 AM, Pascal Robert wrote:

> In that case, do a real 6.0.3 release
> 
> • Switch into the master branch
> 
> • Check the Git history of the integration branch and note the last commit 
> that should be integrated into master 
> (a9426b5ed8a806b6a7292209f8783416bce1a046 is a good candidate for 6.0.3).
> 
> • Do a merge with the commit id of the previous step: git merge -s recursive 
> -Xpatience -Xtheirs XXXXXX
> 
> • Push the release candidate to GitHub: git push origin master
> 
> • Tag the merge with a "wonder-6.x.x" tag:
> 
>       • git tag -a wonder-6.x.x
>       • git push --tags
> 
>> And evidently, I didn't configure my push to push the new 6.0.3 tag :P
>> 
>> Anyway, try the latest master Freddie and see if your problem goes away.
>> 
>> Ramsey
>> 
>> On Mar 30, 2013, at 3:17 PM, Ramsey Gurley wrote:
>> 
>>> 
>>> On Mar 30, 2013, at 11:18 AM, Ramsey Gurley wrote:
>>> 
>>>> 
>>>> On Mar 29, 2013, at 3:37 PM, Ramsey Gurley wrote:
>>>> 
>>>>> On Mar 29, 2013, at 2:27 PM, Freddie Tilley wrote:
>>>>> 
>>>>>>  at 
>>>>>> er.modern.directtoweb.components.header.ERMD2WSimpleHeader.headerString(ERMD2WSimpleHeader.java:25)
>>>>>> 
>>>>> 
>>>>> My wonder says that line is:
>>>>> 
>>>>> return stringValueForBinding(Keys.displayNameForPageConfiguration);
>>>>> 
>>>>> What is your rule for displayNameForPageConfiguration? It doesn't look 
>>>>> like your stack trace goes through ERDDefaultDisplayNameAssignment.
>>>>> 
>>>>> Kieran,
>>>>> 
>>>>> This also looks like a bug in wonder. ERXGenericRecord doesn't handle a 
>>>>> null editingContext() in handleQueryForUnboundKey(). That's going to be 
>>>>> the case on deleted objects. 
>>>>> 
>>>>> I think that should just check 
>>>>> entity().primaryKeyAttributeNames().contains(key) first. That method is 
>>>>> called a lot and there's no reason to be building pk dictionaries every 
>>>>> time. This shouldn't wait for the next integration merge.
>>>>> 
>>>>> Ramsey
>>>> 
>>>> Hmm, even calling entity() repeatedly is going to add overhead. Adding a 
>>>> private static
>>> 
>>> er.. transient :P Can't be static since every eo would share the same 
>>> entity.
>>> 
>>>> entity var may be needed to cache the EOEntity and prevent constantly 
>>>> searching through the models :-/ The other problem I see is that entity() 
>>>> may result in null when there's no ec and the entity is not in the default 
>>>> model group. Not sure how often that happens.
>>>> 
>>>> I'm thinking this method should look something like to prevent the NPE:
>>>> 
>>>> public Object handleQueryWithUnboundKey(String key) {
>>>>    // Handles primary key attribute values
>>>>    if(entity().primaryKeyAttributeNames().contains(key)) {
>>>>            // Deleted object. Return null.
>>>>            if(editingContext() == null) {
>>>>                    return null;
>>>>            }
>>>>            NSDictionary pkDict = 
>>>> EOUtilities.primaryKeyForObject(editingContext(), this);
>>>>            // New object. Return null.
>>>>            if(pkDict == null) {
>>>>                    return null;
>>>>            }
>>>>            // Return value for key
>>>>            return pkDict.objectForKey(key);
>>>>    }
>>>>    return super.handleQueryWithUnboundKey(key);
>>>> }
>>>> 
>>>> Alternately, is this something that we could simply remove and put into an 
>>>> eogen template for anyone who needs this? The more I look at this the less 
>>>> I like it. This method is going to get called a ton for any ERD2W app that 
>>>> uses object.someKey in rules. 
>>>> 
>>>> In my ERUsers framework I have
>>>> 
>>>> 55 : (pageConfiguration = 'CreateERUser' and propertyKey = 'clearPassword' 
>>>> and object.password.length > 0) => componentName = "R2D2WPropertyMessage" 
>>>> [com.webobjects.directtoweb.Assignment]
>>>> 
>>>> Which means the current method is called and creating a pkDict for every 
>>>> single property level component on every single page that isn't an ERUser. 
>>>> I just tested it on a ListMovie page. On a ten item page, 
>>>> handleQueryWithUnboundKey is called 960 times.
>>> 
>>> Also, I obviously need to change the way I'm doing componentName here 
>>> because even creating 960 UnknownKeyExceptions is just excessive.
>>> 
>>>> This is not good. This method needs to be very fast or it needs to be 
>>>> removed.
>>>> 
>>>> Ramsey
>>>> 
>>> 
>>> _______________________________________________
>>> 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]
>> 
>> _______________________________________________
>> 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/probert%40macti.ca
>> 
>> 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/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to