2017-01-20 26 views
1

Я должен хранить большое количество в Realm хранения, как 14000822124935161134. В настоящее время я храню их, изменяя тип их string следующим образом, а затем сохранить его:Лучшее решение для хранения номера «unsigned long long» в Realm

NSMutableDictionary *itemInsert = [item mutableCopy]; 

    if([item valueForKey:@"timestamp"]) { 
     unsigned long long timestamp = [[item valueForKey:@"timestamp"] unsignedLongLongValue]; 
     [itemInsert setObject:[NSString stringWithFormat:@"%llu", timestamp] forKey:@"timestamp"]; 
    } 

    RLMRealm *realm = [RLMRealm defaultRealm]; 
    [realm beginWriteTransaction]; 
    [RMember createOrUpdateInRealm:realm withValue:itemInsert]; 
    [realm commitWriteTransaction]; 

И в timestamp свойство моей RLMObject определяется следующим образом:

@interface RMember : RLMObject 
... 
@property (nullable) NSString *timestamp; 
... 
@end 

Есть ли подходящий тип а не string для данных этого типа в Realm или любое лучшее решение?

+0

Глупая идея, но если это отметка о времени, не могли бы вы просто хранить NSDate? –

+0

Он имеет немного другую структуру, и преобразование в NSDate не рекомендуется. Спасибо любым способом –

ответ

1

Сферирование территории long long; он просто не поддерживает вариант unsigned.

Вы можете просто сохранить значение как long long и предоставить getter accessor, который явно возвращает его unsigned long long при извлечении из базы данных.

@interface RMember : RLMObject 
@property long long timestamp; 
@end 

unsigned long long timestamp = [[item valueForKey:@"timestamp"] unsignedLongLongValue]; 

RLMRealm *realm = [RLMRealm defaultRealm]; 
RMember *myObject = ...; 
[realm transactionWithBlock:^{ 
    myObject.timestamp = (long long)timestamp; 
}]; 

unsigned long long savedTimestamp = (unsigned long long)myObject.timestamp; 
NSLog(@"Saved timestamp is %llu", savedTimestamp); 

Проверено на моем IPad воздуха и, казалось, работает, как ожидалось:

enter image description here

+0

Спасибо, но, к сожалению, это не правильно. 'SavedTimestamp' - это что-то другое значение с первого. Действительным номером является '13951113131432254825', сохраненный номер в базе данных -' -4495630942277296791', а окончательный отображаемый номер - '107202386029632' –

+0

Хм, это любопытно. Я сам испытал это, и насколько я мог судить, он работал так, как я ожидал. Я приложил скриншот того, что я пробовал. Ага! Было бы разумно, что он представлен как отрицательное число в самой базе данных, потому что он сохраняется как «подписанный длинный длинный». Таким образом, хотя двоичные данные точно такие же, они интерпретируются по-разному. До тех пор, пока вы убедитесь, что вы правильно определяете данные, он должен работать нормально. – TiM

+0

Спасибо TiM. Да, это было без каких-либо проблем для второго теста, который у меня был. –