This PR introduces a couple of changes related to where and how data is accessed via a DB client.
Previously we had two different structs for handling registration keys and for handling receiver records (CL scheme), both wrapping *redis.Client.
In place of these two structs we now have two new interfaces, RegistrationManager with method CheckRegistrationKey and ReceiverRecordManager with methods Store and Load. The former is currently used in server-side handlers in both pseudonym system schemes, and will be integrated with the CL scheme in near future as well. The latter is specific for the server-side handler of the CL scheme, and is thus defined the crypto/cl package.
Both interfaces have two implementations: a redis client and a mock implementation. Mock implementations store the data in-memory, and are very convenient for tests - recall that so far, our tests required a running instance of redis database; this is not the case anymore, as mock implementations are now used by default.
If we want to test the client package against an actual redis database, we can run go test -v ./client -db, or invoke the new make target with make test-integration.
Due to rather tight-coupled code, changes in several packages were required. To abstract away the database client implementation, I introduced another change: I moved database access from cl.Org's IssueCred and UpdateCred methods to the corresponding server-side handlers in server package. Due to our current code organization, I had to add a new field clRecordManager to the Server struct, and consequently update the parameters for Server's constructor. This is an ugly hack, but it won't be like that once the project is reorganized to reduce coupling.
This PR introduces a couple of changes related to where and how data is accessed via a DB client.
Previously we had two different structs for handling registration keys and for handling receiver records (CL scheme), both wrapping
*redis.Client.In place of these two structs we now have two new interfaces,
RegistrationManagerwith methodCheckRegistrationKeyandReceiverRecordManagerwith methodsStoreandLoad. The former is currently used in server-side handlers in both pseudonym system schemes, and will be integrated with the CL scheme in near future as well. The latter is specific for the server-side handler of the CL scheme, and is thus defined thecrypto/clpackage.Both interfaces have two implementations: a redis client and a mock implementation. Mock implementations store the data in-memory, and are very convenient for tests - recall that so far, our tests required a running instance of redis database; this is not the case anymore, as mock implementations are now used by default.
If we want to test the
clientpackage against an actual redis database, we can rungo test -v ./client -db, or invoke the new make target withmake test-integration.Due to rather tight-coupled code, changes in several packages were required. To abstract away the database client implementation, I introduced another change: I moved database access from
cl.Org'sIssueCredandUpdateCredmethods to the corresponding server-side handlers inserverpackage. Due to our current code organization, I had to add a new fieldclRecordManagerto theServerstruct, and consequently update the parameters forServer's constructor. This is an ugly hack, but it won't be like that once the project is reorganized to reduce coupling.