Avoid canonical slug conflict in the same project
This adds validations that ensure that wiki pages cannot have the same canonical slug in the same project. We cannot easily move this check to the DB, so this is handled in logic - we check in `.find_or_create` if either of the known slugs matches a record, and we raise errors on conflict. This also introduces some optimisations that eliminate unnecessary queries. Minor updates from review comments Includes: - Use Class#name instead of constant - Wrap mutable state in an outer transaction The one subtle thing here is that the first query (to find the record) must be within the transaction, even though it does not mutate the state of the DB. This is because we learn important facts from that query (namely whether there are any conflicting canonical slugs) that could be invalidated outside a transaction. - Use standard uniqueness validator This is more declarative than our hand-rolled implementation - Move page construction into factory This requires a new trait for the wiki page factory to create pages that are in the wiki repo. - Changes to some test descriptions - Reduce DB queries in specs we don't strictly need multiple slugs here - one will do. - Avoid running validation if there is no project_id - Raise error if there are no slugs at all
Showing
Please register or sign in to comment