Possibility of moving to Int64 for Content Ids

Topics: Core
Aug 26, 2012 at 5:01 PM
Edited Aug 26, 2012 at 5:07 PM

I know this sounds a bit adventurous, but I'm thinking the standard Int32 used for Ids might be a bit restricting in some cases.

I've just run into this very scenario, when writing an orders record. I solved it by removing it as a content part, and making just an ordinary table, with a long type for an Id. But it would have been nice to have it as a contentpart.

Problem being that if I somehow max out the customers at Int32's max value, that would only allow one order per customer, which wasn't gonna work obviously.

I remember playing round with Sun's Project Darkstar a few years ago, and in their wisdom, they used longs for Ids. Now I'm thinking they understand Enterprise software, so they'd probably be right in stipulating that type for an Id.

I know it would make a lot of work in transition, and it may not be fiesible, but it was just a thought..

Aug 27, 2012 at 12:00 AM

Actually, looking at the source this afternoon, it could be quite easy to implement this, I wonder if a fork of the project could provide this functionality to those that need it?

Developer
Aug 27, 2012 at 12:29 AM

See the issue.

Aug 27, 2012 at 12:39 AM

Ah, I see, at least it's a consideration though, and good point, that a table that big shouldn't require additional computation..

Glad to see that it's being thought about, and thanks for the link :D

Developer
Aug 27, 2012 at 12:58 AM

Sorry that no better news :-).

Aug 27, 2012 at 1:03 AM

Well, to be honest, I can work round it, so not a major problem, but I do think that actually implementing a long isn't gonna have a drastic performance impact. Project Darkstar that I mention was a low latency mmo game server, and they had no probs with the long Ids (but bigger problems with network latency). That's not a good example though, cause it didn't scale well last i heard lol..

Coordinator
Aug 27, 2012 at 6:06 AM

To provide some context, we've had this request many times, from people who thought that they may reach the limit. However, no one to my knowledge ever has. Furthermore, if you reach that many content items, it's almost certain that you would hit lots of fun new performance problems and that short ids would be the least of your concerns.

Sep 6, 2012 at 1:05 AM

Personally I would prefer GUIDs. My reason for this is moving toward a more enterprise level of administration with multitenancy, e.g., global navigation, global search, global tags, possibly global content picking or referencing for inter-site linking without link rot, and maybe global users if roles included the ability to reference tenants. If GUIDs were used then they could be carried into the global tables without needing to first map records. This is assuming all site tables are being contained in the same database.

I know there was a discussion on using GUIDs for identity but I don't remember what the specific reasoning was on not being able to use them with NHibernate.

Coordinator
Sep 12, 2012 at 9:35 PM

I strongly veto GUIDs. We have better ways of handling identity, and table IDs columns are internal and don't have to be consistent across instances/datacenters/younameit. Identity is a separate concern (see import/export). If you really want to use GUIDs, by the way, you can: just add the Identity part. It's using GUID as identity for those items that don't have a better one.