How can I define structure of local IDs?

[cfeeling]

How could I add prefix or postfix on local ID which was generated automatically before being sent to sync server?

In my case:

1. every one would register an account on our server, and the identification, with a unique account ID, would be saved in local database after first signing in;
2. client data would be saved separately into their local database firstly. In my mind, I thought that local IDs would be generated locally and WatermelonDB would try to keep it to be unique locally, right? That means it might not be unique on the remote server.
3. I would like to prefix or postfix the identification ID to each local ID before sending them to the remote server to avoid the not-unique-remotely issue, and it also could be used for sharding easily on the remote database.

pseudo-code for transforming local ID:

global.identification = {
    id: 12345,
    name: 'myFirstPet'
};
function transformId(item: Model) {
    return global.identification.id + '-' + item._raw_id;
}

But I did not find any comment about postfixing or prefixing on local ID, could you please help me to resolve it?

[radex]

That means it might not be unique on the remote server.

What do you mean by that? How would this non-uniqueness happen?

But I did not find any comment about postfixing or prefixing on local ID, could you please help me to resolve it?

I'm not 100% sure if I follow what you're trying to achieve (and why). Do you only need to prefix the id field of ID record when using it with the synchronize() function? Or do you want all record IDs locally to be automatically prefixed (and kept that way locally)?

[cfeeling]

@radex sorry for replying it so late.

Lets say, there are two clients in different place, ClientA and ClientB, all generated records in TableA has a field id which would be generated by WatermelonDB, and all records in TableA would be sync to table RemoteTableA on remote database server.

1. ClientA generated a record with id 12345678 in table TableA locally;
2. ClientB generated a record with id 12345678 in table TableA locally (would this case be occurred?);
3. ClientA push the new record to remote database server, then the record with id 12345678 is existed in the table RemoteTableA on remote database server;
4. What would happen when ClientB was sending the push request for the new record which id is 12345678? The remote database server will find the duplicated record and refuse the sync request from ClientB.

I want to resolve the issue occurred in step 4, and prefixing the id field is one of solutions.

If all records generated on ClientA side are prefixed by identification of ClientA, it must be unique on remote database server, all of them should be unique on remote database server.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[netbull]

@radex, I think @cfeeling is right...

1. there is an issue with the random IDs and theoretically a conflict can happen
2. watermelondb currently forces the remote DB to use these random strings as IDs, which for me does not sounds good.

Is it better to use these random strings as temporary IDs until the data is synced with the server. The response of the sync can be a map of the temp ID to a server real ID, then the developer will have the freedom.

I guess making the ID a string is important, so it can be left a string.

Hint: you can add this to the documentation somewhere that if the sync pull response returns data with IDs which are integers WatermelonDB uses the random generator, but if they are strings it's OK.

[radex]

@netbull this was discussed in other issues already. Getting a conflict on a random ID is very, very unlikely. You can absolutely do sync-time ID remapping, but it's a huge pain in the butt when you have relations between objects.

Hint: you can add this to the documentation somewhere that if the sync pull response returns data with IDs which are integers WatermelonDB uses the random generator, but if they are strings it's OK.

Indeed, you can add this :) You can send a quick PR to the docs from the browser: https://github.com/Nozbe/WatermelonDB/blob/master/docs-master/Advanced/Sync.md

[netbull]

@radex the PR is the simplest think to do, but it is useless info if the problem with the IDs is not solved when a record is created locally.

Currently this is stopping me of using the library /I guess many people as well/. I can't change the entire DB in our system just because I want to use WatermelonDB and really it does not make sense.

[radex]

Currently this is stopping me of using the library /I guess many people as well/. I can't change the entire DB in our system just because I want to use WatermelonDB and really it does not make sense.

@netbull Totally understandable! And I think you're right, that this is a problem for a lot of people. I'm waiting for a contributor or a group of willing contributors to come together and come up with a proper solution that will work for everybody.

We don't have this problem at Nozbe, so I can't afford spending time on solving it for other developers. But I'm more than happy to give advice and pointers to the right places in code if other people want to solve it for themeselves.

[netbull]

@radex understandable! That's the meaning of open source, right :)

[cfeeling]

@radex could you please finger out which thread it was discussed in? I'd better to make a reference to it. thanks

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.