I am trying to pull in a RSS feed and sort by pubDate. When I examine the 'updated' property, most of the time it is correct and give me a proper date but when I try to convert from a set to a sorted array, I get random results from the sort. I've tracked this down to the fact that when sort is doing it's comparesion, the property (which is an NSDate, see figure1) is coming in and being compared as a __nscfnumber! (also figure2)
Any help or idea would be much appreciated.
figure1
figure2
I assume the comparator block is just for diagnostic purposes? You don't actually need to supply a comparator for NSDate or any of the provided attribute type classes.
If the debugger is reporting that the date1 object is of a NSNumber-cluster class type, then somewhere a NSCFNumber instance is being assigned to to the updated attribute. The debugger ignores factors like a cast and instead simply asked the object what its class is. If the object says it is a NSCFNumber then it is, regardless of how the code treats it otherwise.
Why that happens, I can't say based on the code provided.
You might try logging the value and class of the updated attribute before you attempt the sort to see if it reports properly. I would also recommend decomposing the entire line. Nesting all those method calls will work of course but it is error prone and hard to debug.
Related
I am getting undefined, when using agent.parameters.geo-country while using the System entity #Sys.geo-country.
This is the error I am getting.
https://drive.google.com/file/d/1-rP9rkvOB3Wm0KyGn846iFbMBFb2Iu9c/view?usp=drivesdk
JSON property syntax (x.y.z) doesn't like the dash. In order to get around that, you can use the alternative bracket syntax (x['y']['z'])
In your case, you could use agent.parameter['geo-country'].
Another thing you can do instead is look at the name of the paramter, and change it if you want.
For example, in the case below, the entity type is #sys.any, but I've named it to search. This means I could instead use agent.parameter.search which may be more useful to me.
I'm trying to create a MutableProperty which holds a Results received from Realm.objects(_:).
To create the property I need to give it an initial value; hence an 'empty' Results.
I've tried creating one using:
var someThings = Results<SomeObject>()
MutableProperty(someThings)
But the compiler gives me the error: Cannot invoke initializer for type 'Results<SomeObject>' with no arguments.
While I understand the error, I'm not really sure how to create a Results object in this context.
Looking at the source of Results I couldn't find an init either.
So my question is; how can I create a Results myself to use in a MutableProperty?
Edit:
I've seen this question...but that doesn't really help (unless I'm going to create a "wrapper" for the MutableProperty or something).
With help of the comments on my OP; I created a mutable property with an empty set of results by fetching objects with an 'invalid' filter.
E.g. MutableProperty(realm.objects(SomeObject.self).filer("EMPTY SET")).
So long story short, there's a discrepancy between the output of a NSMutableDictionary's contents and the result of calling allValues on the same object. Below is some debugger output after inspecting the object which demonstrates my problem: (made generic of course)
(lldb) po self.someDict.allKeys
<__NSArrayI 0xa5a2e00>(
<SomeObject: 0xa5a2dc0>,
<SomeObject: 0xa5a2de0>
)
(lldb) po self.someDict.allValues
<__NSArrayI 0xa895ca0>(
0.5,
0.5
)
(lldb) po self.someDict
{
"<SomeObject: 0xa5a2dc0>" = (null);
"<SomeObject: 0xa5a2de0>" = (null);
}
So as we can see, the actual output of the NSMutableDictionary contains null values for both its entries, but the contents of .allValues contains the proper data. These three outputs were taken at the same time in execution.
I'm not sure why this is happening, but I think it may have something to do with the fact that I'm encoding/decoding the object which this dictionary is a property of using CoreData. I believe I'm doing this properly:
[aCoder encodeObject:self.someDict forKey:#"someDict"];
and to decode
self.someDict = [aDecoder decodeObjectForKey:#"someDict"];
The weird thing is that if I inspect the dictionary before it ever gets encoded, it is still in the state described at the beginning of the post, so this is why I'm doubtful the CoreData actions are screwing with the contents.
As always, please don't hesitate to request additional information.
EDIT: The problem was as answered below. I was using a custom class which didn't cooperate with isEqual, so my solution was to change the storage and structure of my logic, which made using a Dictionary unnecessary.
I have not been able to duplicate the problem using NSString as keys and NSNumber as values. I suspect that your custom class does not properly implement hash and/or isEqual. Specifically, the results from those two methods must be consistent, meaning that if isEqual returns true, then the hash values for the two objects must be identical.
You also need to ensure that your class implements NSCopying properly and that a copy is equal to the original.
As a general rule, don't use custom objects for dictionary keys. Just use strings and be done with it.
As user3386109 points out, custom objects must properly implement the -hash and -isEqual methods in order to be used as dictionary keys, and even then, custom objects don't work correctly for dictionary keys for things like key/value coding.
I've researched tons of questions and documents about CoreData returning faults instead of actual values:
Relationship 'whiskers' fault on managed object (0xb7abab0)
This happens when I'm trying to get the count for the number of whiskers, such as:
self.numWhiskersLabel.text = [NSString stringWithFormat:#"%d", cat.whiskers.count];
Even if I try to log the whiskers set directly I still get a fault:
NSLog(#"whiskers: %#", cat.whiskers);
I understand that "Core data will not return full object until there is a need to access the actual value of that object. Each of your returned objects will be a 'fault' until this point." That's great, but there is a need to access the actual value at this point. I need the value right now! So how do I get out of this oxymoron? How can accessing the count of a Set not be considered needing the value?
I didn't get any feedback from my comment so I'm just going to assume whiskers is a set of NSManagedObjects
The set wont be loaded initially because internally it's coming from another table in the db. When you access .whiskers.count it still doesn't need to go and get the data yet, because all you're wanting is the number of whiskers in the set.
When you pull a whisker out of the set, then it will be faulted, try doing
NSLog(#"whiskers: %#", [cat.whiskers.anyObject anyProperty]);
That should give you a loaded NSManagedObject.
This is an error condition. Something is wrong with that NSManagedObject instance. Either it was deleted before you accessed it or you are trying to touch it from the wrong thread.
Please edit your question and show the code that is accessing that NSManagedObject.
Also, what happens when, in the debugger, you just do a po cat? Do you see the full Cat object or is that giving a fault error as well?
Using Struts 2.1.6, xwork 2.1.2 and ognl 2.6.11
In my struts action I have a Map that I am fetching elements from using OGNL. If the key I am using to fetch with does not exist in the map then OGNL returns an empty object array, that OGNL converts to a string and I get the object reference java.lang.Object#6.... This occurs in several places and seems to be the the map having the value generic specified as an Object. This is not something I can change.
I have traced the problem for a while, but when I ended up deep into the guts of the OGNL code and I did not see a light at the end of the tunnel. Currently I am going to go with an ugly hack of checking the string return to see if it starts with "java.lang.Object#" and if so return an empty string. I don't like the solution but thats what time permits.
Has anyone encountered a similar problem?
Also, where did OpenSymphony go? updates to their webiste appear to have dried up, the user forums say they are being converted to Google Groups no later than Nov-12-09
This is a problem with null values: if value is null, default behavior is to create a value using default constructor. Since the value type of your map is Object, new Objects are created where null is.
In order to stop this behavior:
use #CreateIfNull( value = false )
use mapName_CreateIfNull=false in classname-convertion.properties file.