Needs review
Project:
Entity reference
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
13 Apr 2013 at 04:56 UTC
Updated:
4 Jan 2015 at 22:44 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
zkday commentedThis is a patch. ;)
Comment #2
jasonlttl commentedJust a quick me too...
At our university, we have a system for integrating remote entities from different data sources (HR, student information systems, faculty tenure, etc). We automagically pull these in as locally cached entities. However, our users needed a way to add local override records without going through red tape. So we added the ability to create local entity records. To avoid the potential for id conflicts between remote records and local records, we made the local ids negative just like zkday did above... and then we hit this issue.
As an aside, there's an interesting issue on the field api needing to support textual ids for entities.
https://www.drupal.org/node/1823494
I haven't tested the patch yet, but looking at it, I'd think you'd want to go to bigint instead of just flipping the signed to unsigned (and keeping 4 bit ints). That way, if anyone has ids between 2^31 and 2^32 (2-4 billion), they will continue to work. That said, I would guess that doubling the size of every entity ref field from 4 bytes to 8 bytes could also be something to be careful about.
These are the "standard" and "big" sizes for mysql and probably everything else.
signed 4 bits : -2147483648 to 2147483647
unsigned 4 bits : 0 to 4294967295
signed 8 bits : -9223372036854775808 to 9223372036854775807
unsigned 8 bits : 0 to 18446744073709551615
Another strategy I'm looking at is segregating remote ids and local ids within the positive space.
< 2^31 means remote
> 2^31 means local
This would effectively be the same address space as changing to signed 4 bit numbers but there are some downsides with respect to clarity and collision handling.