Primary key support for int and string columns #868
Conversation
|
@kspangsege Sweet. Right now the only core functionality from core we are using is calling find_first for string and int to ensure uniqueness. Once we have a more efficient way to do this it shouldn't be difficult to switch over. We are not using any indexing as there is an issue with string indexing and int indexing isn't yet implemented. |
|
Can you say more about the issue with string indexes, or point to a related On Thu, Sep 4, 2014 at 2:42 AM, Ari Lazier notifications@github.com wrote:
|
|
I'm not sure there is a specify task. This is the same problem that we discovered when running Group::Verify at every transaction boundary. Here is the callstack of where that fails in the tests: When verify is not used, we get a crash when creating an empty row on a table with a string index. |
|
Ok, thanks for the info. It seems we need more core-side testing of the On Thu, Sep 4, 2014 at 3:16 AM, Ari Lazier notifications@github.com wrote:
|
|
Also, the following test: [[RLMRealm defaultRealm] transactionWithBlock:^{
// IndexedObject has `NSString *name` and `NSInteger age` properties, where `name` is indexed
[IndexedObject createInDefaultRealmWithObject:@[@"nameValue", @0]];
}];yields the following error message: |
Extract duplicated code in setter creation
| @@ -252,6 +299,16 @@ | |||
| */ | |||
| + (RLMArray *)objectsInRealm:(RLMRealm *)realm withPredicate:(NSPredicate *)predicate; | |||
|
|
|||
| /** | |||
| Returns TRUE if another RLMObject points to the same object in a RLMRealm. For RLMObject types | |||
| [propArray addObject:prop]; | ||
| if ([primaryKey isEqualToString:propertyName]) { | ||
| //attr = attr | RLMPropertyAttributeIndexed; | ||
| schema.primaryKeyProperty = [RLMProperty propertyForObjectProperty:props[i] attributes:attr]; |
There was a problem hiding this comment.
[RLMProperty propertyForObjectProperty:props[i] attributes:attr] could be pulled out of the if.
|
@alazier I'm running into the following exception: This happens because I have the following json: Does createOrUpdateInDefaultRealmWithObject not get called on nested objects? |
|
@eni9889 you are correct that upserting nested objects doesn't yet work properly. You can probably work around this by upserting nested objects before the parent - for the data you provided it would be something like: Person *person = [[Person alloc] initWithObject:parsedJSON];
[realm addOrUpdateObject:person.address];
[realm addOrUpdateObject:person];Once we get this fixed you can delete the calls to |
… key values of 0 and ""
And fix some issues with int sizes in obj-c and some Swift initialization stuff in the process. There's three main changes here: 1. Most of the int property stuff now operates on s, i and q separately, so that the properties can actually act as if they were the correct type. This fixes 64-bit properties sometimes getting truncated to 32 bits, 32-bit properties sometimes *not* getting truncated to 32 bites, and 16-bit properties not working at all. 2. RLMObjectSchema is now more similar for obj-c and Swift types, with only the Swift-specific parts handled by RLMSwiftSupport. This was done to solve the problem of that the actual size of the int property was being lost (with everything being collapsed to a single size), but also fixes things like the object type of array properties not being validated, and makes primary keys work for Swift. 3. There's now a dummy implementation of RLMSwiftSupport for Xcode 5 so that the only `#if REALM_SWIFT` checks are for which header to include, rather than making some of the actual logic a mess.
Add full support for sized Ints in Swift
alazier
changed the title
| @@ -572,43 +604,56 @@ void RLMDynamicValidatedSet(RLMObject *obj, NSString *propName, id val) { | |||
| userInfo:@{@"Property name:" : propName ?: @"nil", | |||
| @"Value": val ? [val description] : @"nil"}]; | |||
| } | |||
| RLMDynamicSet(obj, (RLMProperty *)prop, val); | |||
| RLMDynamicSet(obj, (RLMProperty *)prop, val, prop.isPrimary, false); | |||
|
Is there a test for trying to upsert a type without a primary key? I think that's the only thing missing. |
|
I think this is basically ready for merge. I've been developing on top of it to avoid conflicts and haven't noticed any regressions. |
|
Any other comments? |
|
|
||
| ### Bugfixes | ||
|
|
||
| * Realm change notifications when beginning a write transaction are now sent | ||
| after updating rather than before, to match refresh. | ||
| * `-isEqual:` now uses the default `NSObject` implementation unless a primary key | ||
| is specified for an RLMObject. In the case a primary key is specified `-isEqual:` calls |
There was a problem hiding this comment.
Can you rephrase to
When a primary key is specified,
-isEqual:calls-isEqualToObject:and a corresponding implementation for-hashis also implemented.
There was a problem hiding this comment.
Sorry if this was mentioned but will nested object support be included in
this merge?
Sent from my iPhone
On Sep 9, 2014, at 3:44 PM, JP Simard notifications@github.com wrote:
In CHANGELOG.md:
Bugfixes
- Realm change notifications when beginning a write transaction are now sent
after updating rather than before, to match refresh.
+*-isEqual:now uses the defaultNSObjectimplementation unless a primary key
- is specified for an RLMObject. In the case a primary key is specified
-isEqual:calls
Can you rephrase to
When a primary key is specified, -isEqual: calls -isEqualToObject: and a
corresponding implementation for -hash is also implemented.
—
Reply to this email directly or view it on GitHub
https://github.com/realm/realm-cocoa/pull/868/files#r17333242.
There was a problem hiding this comment.
@eni9889 yes there is support for nested objects in this pr.
Primary key support for int and string columns
|
👍 over 9000 |
Also support for upsert for objects which have primary keys.
Missing: