This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
Currently this is implemented internally as a second method call. In the
future, it might be possible to optimize the implementation, e.g. to
reduce the amount of DB queries/jobs etc. without changing anything for
callers.
Since the implementation of e.g. the result getters is generic, a future
commit may add an option to delete subpages with relatively low effort.
The revision limit for big deletions is now using the total number of
revisions (base page + talk page). This is because both deletions would
happen in the same main transaction, and we presumably want to optimize
the deletion as a whole, not as two separated steps. This would become
even more important if the aforementioned improvements are ever
implemented. Note, the whole concept of "big deletion" might have been
superseded by batched deletions in the author's opinion, but as long as
such a limit exists, it should serve its purpose.
The current interpretation of the associated talk option is that the
request is validated, and an exception is raised if we cannot delete the
associated talk, as opposed to silently ignoring the parameter if the
talk cannot be deleted. The only exception to this is that it will not
fail hard if the talk page turns out not to exist by the time the
deletion is attempted, as that's hard to foresee due to race conditions.
Note that the summary for the talk deletion is prefixed with the
delete-talk-summary-prefix message. The main reason behind this is that
the delete UI can sometimes offer an auto-generated summary like "the
only contributor was XXX" or "the content was YYY", and since this may
not apply to the talk page as well, the log entry might look confusing.
Bug: T263209
Bug: T27471
Change-Id: Ife1f4e8258a69528dd1ce8fef8ae809761aa6f1d
In retrospect, I rushed the previous patch: we really need a way to tell
which deletion an ID belong to (and whether it was scheduled). So make
both result getters return an array with known keys that can be used
programmatically. Right now the class can only delete a single page, and
thus there's a single constant and this change is effectively a noop.
The deletionWasScheduled() method, introduced in 1.37, was
hard-deprecated out of an abundance of caution. There are no known uses
on codesearch, so it can probably just be removed in the next release.
Also reorder constructor params to DeletePage -- BacklinkCacheFactory is
a service injected by the factory, hence it shouldn't be grouped
together with value objects injected by the caller.
Change-Id: I32679b7cacc638ec3e9dc5b8dfe9bcc794b22ecf
Instead of putting logID/false in the status' value, add getters that
can be used to retrieve this information. Also, make it return an array
of log IDs, which is easier to expand later on to account for deletion
of related pages (e.g. associated talk page).
Note: this change will be backported to 1.37.
Bug: T288758
Change-Id: I7ef64242ae0cb7018a4b1e8eb004a5563925b9a4
Some methods in the PageUpdater's class implements the fluent interface
design pattern. Use the fluent interface where need be.
Change-Id: If76a4b8c5070c20ed40038a4ee78e2d677de5180
- Switch do actual DI
- Add some more parameters for needed dependencies
- Create a factory interface, implement it in PageCommandFactory and add
wiring for it.
- Add new unit tests for DeletePage; unfortunately, this requires
conditionally disabling some code during tests due to dependencies on
legacy code that hasn't been migrated yet. I believe that these
temporary hacks are acceptable, since they allow us to use real unit
tests immediately.
- Adjust WikiPageDbTest: the two logging tests were identical as of
Ie0d9da2c8d273c93301921e1e108d9ffb381b8a5; and then the logging part
could just be part of the "main" test.
- Add integration tests for DeletePage. For now, these are all copying
their WikiPageDbTest counterpart. More tests will be added soon™.
Bug: T288758
Change-Id: I2fb79ed905ce621cb87f0658983d97148948da28
