Support for string ids (file ids, etc)

[PVince81]

Follow up of #20401 and #20394 regarding string id discussion

@DeepDiver1975 @icewind1991 @karlitschek

[PVince81]

@DeepDiver1975 was there any update on this discussion ?

Moving to 9.2

[PVince81]

@DeepDiver1975 @butonic moving to backlog for now, not sure where we are with the discussion about string ids but this is still a huge task with big potential for regressions.

[butonic]

will give us headaches with functions like Cache::get() that allow int and string. Personally, I would be happy to get rid of them.

If we use strings we need to add the storage to the primary key, because with strings we no longer have an autoincrement column that we can use to spit out the next fileid. Instead we have to move that logic to the storage. a fallback might be a uuid ... but maybe there are better alternatives.

[ckamm]

@PVince81 @butonic The desktop client will start querying and storing oc:fileid (for local links) - shall we consider this an integer or a string, to be safe for the future?

[guruz]

I would stay with string. Although one could have "Id" as string but "fileid" as numeric also in future.

…

On 9. May 2017, at 10:40, ckamm ***@***.***> wrote: @PVince81 @butonic The desktop client will start querying and storing oc:fileid (for local links) - shall we consider this an integer or a string, to be safe for the future? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.