• I would like to use a unique identifier in WordPress instead of the autoincrement idea which is the WP standard approach, to facilitate integration with other applications.

    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.

    The trouble starts when WP retrieves the primary key, and casts it as an integer. In order to ensure a reasonable chance of the key being unique, I am using PHP’s uniqid() function, and converting the hex result to base 10. In PHP, this is a float, because a PHP integer is limited to 2 billion odd, and the unique id is way bigger.

    All the primary keys in WP are defined as BIGINT, so MySQL has no difficulty in managing the larger value.

    Question is what is the logic in defining the database column as BIGINT and then casting the value returned from the database to INT? More to the point, am I going to get into major trouble somewhere along the line if I remove all the “(int)” castings in the WP core?

    I would really prefer not to hack the core at all for all the obvious reasons: is there any other way to work around this?

    Regards,

    William.

Viewing 4 replies - 1 through 4 (of 4 total)
  • If you’re expecting an integer from the database, then naturally you would cast to INT when retrieving values that are expected to be an INT, in the same way you might also cast values expected to be strings into strings..

    In order to ensure a reasonable chance of the key being unique

    Why wouldn’t it already be unique, is there some insight in your research that’s absent from your question? (ie. do you know something i don’t that you’ve not covered above).

    Big int will be good upto a value of 18446744073709551615 unsigned, are you honestly expecting to exceed that?

    Thread Starter NettSite

    (@nettsite)

    Hi Mark,

    Thanks for the reply.

    I need the key to be universally unique, at least within the domain of 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.

    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, where I need it to be something different in each website so that I can merge the data from each website into every other website.

    Hope that is a bit clearer!

    I am trying using PHP’s uniquid() function to generate the key, and that produces a 13 character string, which converts into a decimal which is smaller than a BIGINT in MySQL, so that is cool, and my override for wpdb successfully writes it into the database, but PHP’s integer is much smaller – a little over 2,000,000,000, I can’t remember offhand the exact size. When PHP receives the BIGINT from MySQL, it would normally manage it as a float because it is bigger than PHP’s int, but casting it as int in PHP has the effect of truncating it.

    So, I am going to try and remove the “(int)” casting and see if that solves my problem, although as I said earlier I would prefer not to make changes to the WP core at all.

    I am concerned, though, that doing so may solve my immediate need and leave me with a worse problem somewhere else, and wondered if anyone had followed this path before, and also why the original authors had done the 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.

    Regards,

    William.

    Ok i think i follow you better now, but what areas of core code/functions are you specifically referring to when you say..

    The trouble starts when WP retrieves the primary key, and casts it as an integer.

    ..(so i don’t need to go back tracking through the code, as it appears you already have)..

    Certainly an interesting question/topic, and i’ll be happy to dig around the associated code to see if any simple solutions spring to mind, but it may simply be something you’ll have to hack into core(typically a WordPress installation doesn’t need to support the kind of functionality you’re aiming for).

    I’d also suggest posting this on wordpress.stackexchange.com, it might help get some more experienced eyes on the topic(just be sure to read the FAQ on how to ask questions).

    Thread Starter NettSite

    (@nettsite)

    Hi Mark,

    Upon scratching around in the code I have found that the casting to an integer is all over the place – doing a text search on a new install of WP 3.3 finds over 600 instances of “(int)”. In addition, there is a absint() function in functions.php which returns the absolute integer value of anything passed to it, which is also liberally called.

    It would be nice to understand why this is done, it seems to be a deviation from “best practices”.

    “PHP does not require (or support) explicit type definition in variable declaration; a variable’s type is determined by the context in which the variable is used.” (PHP Manual)

    I have followed your suggestion and posted on wordpress.stackexchange.com as well, with no responses so far.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Converting WP primary keys to UUID’ is closed to new replies.