Serializing NSNumber
pcrawfor
for the work on this :)
I have subclassed sqlitepersistenobjects for local storage and am
using ObjectiveResource for remote interaction.
I ran into a snag with serializing NSNumber attributes for remote
create and update calls. I have a number of attributes that I store
as NSNumber's in float format, so they need to be accessed via
floatValue and it seems like the standard serialization doesn't handle
it.
I've writted a simple category for NSNumber based on those in the
library which overrides the
- (NSString *)toXMLValue;
and
- (NSString *)toXMLElementAs:(NSString *)rootName excludingInArray:
(NSArray *)exclusions
withTranslations:(NSDictionary *)keyTranslations;
functions and this seems to do the trick for the float NSNumber
values.
I just wanted to see if I was missing something or if you had intended
that NSNumbers be supported in some other way. If not I can pass
along the code for the NSNumber extension.
Thanks again guys!
Paul
pcrawfor
- after looking at the github repos - I downloaded from your 1.0
announcement
Adam
they may have for this but I would definitely be interested to see
what you've done either way. Thanks for offering to share,
Adam
Josh Vickery
>
> Hey I am working with Objectiveresource and its great so far, thanks
> for the work on this :)
> I have subclassed sqlitepersistenobjects for local storage and am
> using ObjectiveResource for remote interaction.
Oh good, I'm thrilled to hear that someone else is doing this as well.
This is the primary reason why we made ObjectiveResource a category
rather than a super class. We have an experimental project that
attempts to wed ObjectiveResource with a local ORM that we are calling
ObjectiveSync (http://github.com/yfactorial/objectivesync/tree/master).
We ran into some troubles with SQLitePersistentObjects and ended up
making some serious changes, so that's in there as well in the
"ObjectiveRecord" directory. If you want to have a look at
ObjectiveSync, that would be awesome since it hasn't been getting any
love recently.
> I ran into a snag with serializing NSNumber attributes for remote
> create and update calls. I have a number of attributes that I store
> as NSNumber's in float format, so they need to be accessed via
> floatValue and it seems like the standard serialization doesn't handle
> it.
It turns out that we (I, really) messed up NSNumber handling in the
ObjectiveResource 1.0 release. If you were to dig into the code with
the debugger, you would see that it only works because of
Objective-C's loose typing. We started to fix it for the 1.01 bugfix
release, but realized that the fix would change the API and the sample
code, so the fix has been pushed back to 1.1.
> I've writted a simple category for NSNumber based on those in the
> library which overrides the
> I just wanted to see if I was missing something or if you had intended
> that NSNumbers be supported in some other way. If not I can pass
> along the code for the NSNumber extension.
I thought that serialization was working with 1.0, but it's quite
possible that it's not. If you would be willing to post your changes
here, or create a ticket for them on lighthouse
(http://yfactorial.lighthouseapp.com/projects/18393-objectiveresource/tickets/new)
that would be much appreciated, and if it doesn't break any of the
unit tests (which I'm guessing it won't) it would be great to include
it in the 1.01 release.
We are getting ready to post the 1.01 bugfix release
(http://yfactorial.lighthouseapp.com/projects/18393-objectiveresource/tickets/bins/14713)
and after that we will be branching for work on 1.1
(http://yfactorial.lighthouseapp.com/projects/18393-objectiveresource/tickets/bins/14714).
The 1.1 release is going to include a number of changes that will
require changes to existing code. One of the first things we will fix
will be the NSNumber handling
(http://yfactorial.lighthouseapp.com/projects/18393-objectiveresource/tickets/44-update-sample-app-to-include-nsnumbers#ticket-44-3).
pcrawfor
I got latest from your github project and merged it into my project
and it looks like the two fixes that I had added for NSNumber and
NSDate are in there already with virtually the same changes.
Your latest also fixed an issue I had hit with trying to instantiate a
single object using findRemote when that object had a two word class
name
eg. bigDog which gets the xml tag big-dog
I am thinking you must have hit that one as well :)
I don't think I have anything to add that goes beyond your current
stuff at least the current version is working for what I need with a
couple of very minor changes to things like the username/pass
credential storage and such.
Can I ask what kind of problems you were hitting with
sqlitepersistenobjects?
I am using an async queue to push local changes out our rails app in
the background and I a little worried about the lack of thread safety
in sqlitepersistenobjects.
At the moment I am using the synchronized directive on the sqlite db
object to try and keep the access thread safe, but it feels a little
naive.
Thanks again,
Paul
On Feb 26, 4:36 am, Josh Vickery <vicke...@gmail.com> wrote:
> unit tests (which I'm guessing it won't) it would be great to include
> it in the 1.01 release.
>
> We are getting ready to post the 1.01 bugfix release
> require changes to existing code. One of the first things we will fix
> will be the NSNumber handling
Josh Vickery
> and it looks like the two fixes that I had added for NSNumber and
> NSDate are in there already with virtually the same changes.
> Your latest also fixed an issue I had hit with trying to instantiate a
> single object using findRemote when that object had a two word class
> name
> eg. bigDog which gets the xml tag big-dog
> I am thinking you must have hit that one as well :)
on the github master branch.
> Can I ask what kind of problems you were hitting with
> sqlitepersistenobjects?
> I am using an async queue to push local changes out our rails app in
> the background and I a little worried about the lack of thread safety
> in sqlitepersistenobjects.
> At the moment I am using the synchronized directive on the sqlite db
> object to try and keep the access thread safe, but it feels a little
> naive.
Thread safety is a big one. I also found the object cache to be
problematic from a memory management perspective.
The forked version that I've been using removes the object cache and
moves all database access to a single, synchronized method
(http://bit.ly/4C7EI). The fork unfortunately does away with
collection and association support, since I didn't need them, and it
made the other changes a lot easier to implement.
Josh