Converting primary keys from autoincrement integers to UUIDs

The Goal

I’d like to have WordPress use a unique identifier instead of auto incrementing on the primary key, which is currently the WP standard approach, in order to facilitate integration of several WP websites.

The Reasoning

I need the key to be universally unique, at least within the domain of the several WordPress websites. The idea is to synchronise posts and other data between the sites in such a way that a post created on any site is available to every other site as well. The different websites will be on different servers in different locations.

Read More

The Issue

The autoincrement functionality which WP relies on will clearly cause the same key to be used in the corresponding table of each WP site for different posts, i.e. the first post in each website will be 1, whilst I need it to be unique across all installations so that I can merge the data from each of them into every other website.

When WP retrieves the primary key it casts those values to integer. When PHP receives the BIGINT from MySQL, it would normally manage it as a float because it is bigger than PHP’s int limit, but casting it as int in PHP has the effect of truncating it in my case.

What i’ve done so far

I am currently using PHP’s uniquid() function to generate the key which produces a 13 character string, which then converts into a decimal in the area of 1388661576514060 (tonight), which is smaller than a BIGINT in MySQL (up to 18446744073709551615), so that’s cool and an override i’ve applied to wpdb successfully writes it into the database, but PHP’s integer limit is much smaller, up to 2147483647.

It is fairly straightforward to do this by overriding the insert_replace helper function and the query function in wpdb with functions in a new class which set and remember a unique value to be used as a primary key.

I’m currently aiming to try and remove the (int) casting and see if that solves my problem, though i’d prefer not to make changes to the WP core, it appears it may be my only option.


Thoughts

I am concerned with taking this approach, because whilst it may solve my immediate need it could cause worse problem somewhere else down the line and i’m wondering if anyone had attempted something similar before.

Additionally i’m curious as to why the developers have used specific casting – I love PHP’s loose data typing, so it’s not something that I would do unless there was a specific reason. I have sufficiently burnt fingers to respect other programmer’s reasons enough to try and find out what they are, thus the question.

I would really prefer not to hack the core at all for all the obvious reasons, could anyone offer and thoughts or ideas on how to work-around this problem or alternatively a different way to approach it?

Related posts

Leave a Reply

1 comment

  1. Modifying and re-purposing core fields in posts database is not advisable. Core behavior might easily change and break it.

    It is trivial to store any additional info in custom fields which is meant for abitrary data and does not interfere with normal mechanics.