Closed felixLam closed 10 years ago
The main reason we need to emulate AUTOINCREMENT is to ensure that instances in memory always have valid primary-key values, even when created with +new
. Using SQLite's built-in implementation would cause there to be no primary-key value set between +new
and the new instance's first call to -save
.
To clarify, the issue is that you were using AUTOINCREMENT before, and now, rather than using the emulation, you want the random-integer keys?
If so, I imagine this is a narrow enough use-case that it's not worth special-case handling in the code — what if you just override primaryKeyValueForNewInstance
in that subclass, with a copy of the random-int code from FCModel?
@import Security;
//...
+ (id)primaryKeyValueForNewInstance
{
uint64_t urandom;
if (0 != SecRandomCopyBytes(kSecRandomDefault, sizeof(uint64_t), (uint8_t *) (&urandom))) {
arc4random_stir();
urandom = ( ((uint64_t) arc4random()) << 32) | (uint64_t) arc4random();
}
int64_t random = (int64_t) (urandom & 0x7FFFFFFFFFFFFFFF);
return @(random);
}
FCModel would take care of duplicate-checking when calling this function, so this is all you'd need to do.
Don't get me wrong I am all for the removal of the AUTOINCREMENT
and understand the reasons behind it. I was wondering what the harm would be to always use the random integers even if primary keys have an AUTOINCREMENT
flag.
I will use the method you mentioned. Thanks for your help.
From my understanding sqlite treats all primary integer key columns as "somewhat" AUTOINCREMENT: http://www.sqlite.org/faq.html#q1
Is the legacy treatment in +primaryKeyValueForNewInstance really necessary? Would it be possible to introduce a macro to disable it?
While we have updated the model to remove the autoincrement, our alpha app tester have a good bit of valuable data in the old scheme (autoincrement is a pain to remove). Is there an issue I overlooked when running the new logic on old schemes (as a temporary measure)?