sql_catalog: No need to check for type
In case uid=0, its already being treated as int, so there is no need to check for type and add time to performance.
-
Owner
>>> 0L is 0 False >>> 0L == 0 True
In your message commit, you must explain why the comment you remove is wrong. If you can't, then it's your change that is wrong.
The history behind long/int/zero uids is so old I don't even know it.
/cc @vpelletier
-
Owner
The idea is that some tools used to have
uid = 0
(so an int) as class property.Then, in some cases where the uid generator broke (in the era when we used to pre-allocate empty catalog rows using SQL autoincrement I think, @jerome and @romain may remember it better than me), it would sometime generate
uid = 0L
(so a long) as instance property. The idea here was to generate a new UID when a long-zero is found, to try to recover from this.But I think this change is correct independently from this, because
uid = 0
is de-facto forbidden in the relational database (where there is no distinction between int and long anyway) as the uid generator starts at 1. So if a document of any type ever ends up in this code with uid == 0 it should always get a new uid (and accept getting one) to not break this expectation. -
Owner
Ok, the change looks correct, but I don't understand « The idea here was to generate a new UID when a long-zero is found, to try to recover from this. »: before this commit, we didn't generate a new UID in case of 0L.
Anyway, we should go further. Simply:
if not uid:
And while we're at it, there's another
isinstance(uid, int)
below. -
Owner
before this commit, we didn't generate a new UID in case of 0L.
Good point. Maybe it was when tools were getting indexed for the first time then ? But I do not see why
foo.uid == 0L
should not be given an uid either...+1 for fixing other occurrences and simplifying the
if
. -
before this commit, we didn't generate a new UID in case of 0L.
it was when tools were getting indexed for the first time then
Exactly, I see we were simply neglecting generating newUid for the case when
uid = 0L
before this commit. We were having other checks foruid = 0L
though.And regarding another
isinstance(uid, int)
, this doesn't concern the case ofuid=0L
anymore, given that we already will have a new uid generated for this case now.