24.11.2018 13:17, Dimitry Sibiryakov wrote:
24.11.2018 6:43, Dmitry Yemanov wrote:
It could be, but new system generator is also an ODS change. IIRC, we
don't have a safety gap between system and user generator IDs.
It doesn't need to be a system generator. Plugin is free to create a
user one (as well as any other database object) if it needs. Auth
plugins already does that.
Good plugin should never clash with user-defined metadata. Any hardcoded
name for user-defined metadata objects is a subject of potential
conflict. Using RDB$ prefix for non-system objects is a hack I'd rather
avoid. What other options do you see?
I probably missed that. Do you speak about dbb_id (filesystem level
ID) or something more persistent?
I don't know what Alex uses for that. Avalerion provided to crypt
plugin exactly the same database identification GUID that you made.
Where is it stored in Avalerion?
The sequence I was talking about is just to provide contiguous
numbering of journal files.
Journal files or transactions?
Files.
I ask because I see no need in continuous numbering of files.
FireSwarm, for example, uses number of the first transaction for that.
Imagine your last replicated file was marked with ID = 1000. Then you
see file marked with ID = 1010 in the pipeline. How can you be sure that
some other file (e.g. marked with ID = 1005) is not missing (lost by the
transport or not yet delivered)? Do you just continue with fingers
crossed hoping that there won't be conflicts due to missing data, or due
to transactions replicated out of order (if #1005 finally appears after
you processed #1010)?
I know I'm somewhat paranoid, but things never happen as expected in
real life. Early problem detection is a good thing, IMHO.
Dmitry
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
