-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move Mnesia-specific code to rabbit_db*
modules
#6430
Conversation
e2486e4
to
41627e0
Compare
41627e0
to
2c5d75e
Compare
I converted this patch back a draft. I'm preparing another patch to sort out the Mnesia directory issue. I will later update this patch accordingly. Update: See #6462. |
2c5d75e
to
bc523c3
Compare
This comment was marked as spam.
This comment was marked as spam.
bc523c3
to
1f5370e
Compare
The second argument is a list of tuples, not one tuple.
One testsuite was using strings to check the non-existence of a user and a virtual host. Given these names are expected to be binaries, for sure strings won't match.
…time_parameters` So far, `rabbit_runtime_parameters` could be called with invalid terms. There are probably still places in the code which lack this kind of verification.
RabbitMQ lacks argument verifications in many places unfortunately. Several testcases were passing bad arguments to the command but were also comparing the result to bad data. This happened to "work"...
1f5370e
to
527984c
Compare
The idea is to isolate in those modules the code to handle the records in the database. For now, we only support Mnesia, but there is work in progress to move to another database engine. Doing this reorganization of the code will also isolate the changes of this upcoming database engine switch, making them easier to rebase and review. In the end, the `rabbit_db*` modules should export functions for each operations we want to perform. Things like "add this record", "list records matching that", "update a record using an anonymous function inside a transaction", etc. Only the following subsystems are impacted in this commit: * virtual vhosts * internal users * runtime parameters They were modified together because they depend on each other.
This patch adapts several testcases to this behavior change. The goal is to avoid transactions where there is no need for one.
527984c
to
46b71e8
Compare
This change was intended to be a non-functional change. In the end, it's not entirely the case: deleting a non-existing vhost or user succeeds (the delete operations are idempotent). Before, it would have thrown an exception. This simplifies the transactional code a lot. |
…eted This was the case before the reorganize of the code made in #6430 and therefore a regression in the mentionned pull request. This patch restores the behavior. Note that this is already like that for internal users. Thus, the behavior and `rabbit_db_*` are consistent.
This should have been handled in #6430 but was missed unfortunately.
This should have been handled in #6430 but was missed unfortunately.
The idea is to isolate in those modules the code to handle the records in the database. For now, we only support Mnesia, but there is work in progress to move to another database engine. Doing this reorganization of the code will also isolate the changes of this upcoming database engine switch, making them easier to rebase and review.
In the end, the
rabbit_db*
modules should export functions for each operations we want to perform. Things like "add this record", "list records matching that", "update a record using an anonymous function inside a transaction", etc.Only the following subsystems are impacted in this commit:
They were modified together because they depend on each other.
It is a preparation step to be able to change the database layer.