[wp-trac] [WordPress Trac] #19111: Post ID by Hash

[WordPress Trac]

#19111: Post ID by Hash
-------------------------+------------------------------
 Reporter:  braydonf     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Database     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |
-------------------------+------------------------------

Comment (by braydonf):

 Replying to [comment:6 scribu]:
 > Related plugin: [http://wordpress.org/extend/plugins/local-storage-back-
 up/ Local Storage Backup].

 That looks useful for writing as the post will be stored in a browser
 local storage, but uploading media is tied to the server still. Also
 wouldn't be able to view any posts that were not already looking at. It's
 good proof-on-concept of using local storage in the browser.

 >
 > So, if we switched to hashes instead of numerical ids, what would happen
 to all the existing sites when they upgrade to the new version of
 WordPress?
 >
 That would be a huge problem. GUIDs are currently stored using the ID and
 many blogs that are not using pretty permalinks would be affected by the
 change. Internally, the whole process could be automated to update all of
 the IDs in the database. It would be a significant enough change to
 provide some sort of optional opt-out, to avoid any potential problems.
 There are also likely many plug-ins that are depending on the ID to be
 numerical and not a hash, and these would also be affected. So if this
 were to change, it would need to come along with some other changes that
 would make the change warranted. The biggest example I can see would be a
 offline admin interface that is built around using localstorage, or some
 other type of database that can be used on a users local machine, where
 plugins wouldn't be able to be run likely without being updated. How would
 we run PHP locally, which is probably a larger part of this than IDs.
 >
 > Also, won't using hashes slow down complex queries, such as multi-
 taxonomy queries?
 I don't know enough about MySQL queries, unfortunately, to know if a
 numerical ID or hash would be faster or slower. I do know that numerical
 and incremented IDs are very common with relational databases, so I'll
 assume that there is a reason.

 Replying to [comment:7 dd32]:
 > Post ID's are unique to a single install, and thats the way they should
 stay.
 >
 I'm not seeing anyway around it at this time, especially considering terms
 and taxonomies are all using numerical incremented IDs.
 >
 > If you're publishing to multiple installs which are sharing data in that
 way, you shouldn't be relying on the post ID to stay continuous, it should
 be updated on merging upstream/downstream.  You could turn the Guid field
 into a hash/UUID for that specific purpose if it helped.
 >
 Yes, this could be useful for that, at the level of feeds for sure. #19110
 #6492
 >
 > One alternative would be to start the post ID's for blog1 at 750,000
 post ID, the second at 1,500,00, etc (Done by setting the auto increase
 value on the database).
 >
 That could work assuming that there is enough organization.
 >
 > In the end, post ID's are the least of your worries in that scenario,
 you'll have to remap more than just the post ID (Term ids, etc) and deal
 with multiple versions of content..
 >
 I didn't realize this, that's a great point.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/19111#comment:8>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software