24.11.2018 11:42, Dmitry Yemanov wrote:
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?
While namespaces are not implemented - use plugin-defined prefix. Such as
SRP$ or SEC$.
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?
Variable part of database header.
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)?
FireSwarm operates with transaction granularity. File names are not important as long
as they have ascending order, so what you use for files, I use for transactions.
When I see that a peer has transaction 1010 but I have only 1000, I'll request
transaction 1001. No holes is allowed by default.
In contrast to you, I use "pull" technology. Target node is controlling data
flow.
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)?
This is an option, but it is not implemented yet.
I know I'm somewhat paranoid
Not enough. There are much more cases of possible failures. Undelivered or lost
transaction is the simplest one, easily fixed without manual intervention.
For example consider a case when a database was restored from backup and next file has
smaller number than already applied.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
