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]
