Move users to own auto-increment page id?

[netcarver]

I'm working with a client that uses PW to provide the basis for various services, and GDPR/legalities mean that the data for our EU-based users has to live on an EU-resident server. Similarly, US-sourced data has to live on US-resident servers. As the sign-up rates are different in each region, the page IDs between the sites quickly get out of sync, so when new features involving pages are added to the US and EU sites, the IDs of the pages housing new options/blog posts etc are out of sync between them - making references to the pages in the code-base using the page ids impossible.

The only thing causing the desynchronisation between the installs is the user pages.

I know we can use different programmatic techniques to reference these feature/structural pages, but I'm curious; is it possible to force users (any page using the user template - or any alternative user template) to use a separate auto-incrementing id in PW?  I don't think so, but if it could be done, how would you approach this?

Being able to have fixed ids for landmark pages, despite differing sign up rates across regions, would be handy.
 

[DaveP]

Probably not an optimal solution, but maybe you could create a 'dummy' user on the 'other' server at the time a genuine new user is created? Then there's a chance both servers will match, although race conditions etc...

[netcarver]

Hi @DaveP, thanks for the idea.  Hadn't thought of that - but I think it will become difficult to pull off, especially if we extend to other regions and have to sync 3 or 4 (or more) installations.

[teppo]

19 hours ago, netcarver said:

is it possible to force users (any page using the user template - or any alternative user template) to use a separate auto-incrementing id in PW?

Pages::___save() method has a forceID parameter:

	 * - `forceID` (integer): Use this ID instead of an auto-assigned one (new page) or current ID (existing page).

I've never tried to do anything like this, but it seems like this would be a good place to start, e.g. hooking before this method and forcing the ID in case of a new page using the user template. You would still have to figure out some way to share auto-increment ID values between instances ?

[netcarver]

@teppo, that might work if we combine it with an idea from @adrian. If we set a high initial value for ids (say 1 million) and allow pages using the user template(s) to use these independent autoincrement IDs at whatever rate the users sign-up at. We could try using our own, sub-1,000,000 counter value when adding pages with any other template. There won't be that many of them and we going to share these pages amongst all the installations anyway.

[wbmnfktr]

Why not use a custom page name as a reference/ID across those instances?

You could create those "on the fly" when someone is signing-up and therefore that "ID" would be unique.

us-[timestamp]-{page->name}
eu-[timestamp]-{page->name}

Sure... using Page IDs is way easier, yet creating your "own ID" or using a "foreign key" could be an option.
Needed this within a product catalogue (not users) but still. It worked out quite well.

[Robin S]

One more possibility: get your non-user pages by path instead of by ID. If you use PagesLoader::getByPath() it should be just as robust as getting by ID because page path history will handle any renaming or moving of pages. And as a bonus the code is more readable because it's more obvious what page is retrieved by '/about-us/sustainability/' than by 24875.

$p = $pages->loader()->getByPath('/about-us/sustainability/', ['useHistory' => true]));

 

[rick]

Maybe I'm off base here, but since you say the user is the issue, why not create your own ISAM routine by hooking the registration to it's own domain/database and passing the result to the proper installation login/user.

[kongondo]

Late to the party but I agree with the approach by @rick. This is a database layer issue and I would approach it with a database solution, in the first instance, instead of a code one (hooks, forcing IDs, etc).  Given, the forceID flag was added for a reason but for an operation of the scale and intricacy you are dealing with, I'd let the database handle IDs. The 1M idea is clever but given that you are enforcing it through code, it takes one or two mistakes/glitches and you could end up with some 'lost' users (e.g. with IDs < 1m).