| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
| |
This includes making making sure that xapiandbs directory is moved
with this version of the code.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were seeing errors in xapian_create_job that indicated that the
current transaction had been aborted but not rolled-back. It seems
that this happened because sometimes xapian_create_job was called
from within another transaction (e.g. from the transaction block in
AdminIncomingMessageController#redeliver). The default behaviour
of nested transactions in Rails is for them to behave as if all
but the outermost transaction blocks had no effect; this means
that the exception thrown in the inner transaction block in
xapian_create_job wasn't causing a rollback, and it was then being
caught before propagating up to the outermost transaction. Thus
the transaction was never being rolled-back so any subsequent
operation on this database connection would error.
This commit fixes this problem by using the :requires_new => true
option to transaction, which asks ActiveRecord to fake genuinely
nested transcations using SAVEPOINT.
Fixes #1124.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Conflicts:
vendor/plugins/acts_as_xapian/lib/acts_as_xapian.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The spec uses a hook method to simulate the insertion of an
acts_as_xapian_job in another process for the model.
Credit to: http://stackoverflow.com/questions/2017587/simulating-race-conditions-in-rspec-unit-tests
Conflicts:
vendor/plugins/acts_as_xapian/lib/acts_as_xapian.rb
|
| | |
|
|/
|
|
|
|
|
| |
Check to see if the stripped version is different before setting it on
the record. If we don't do this, the subsequent call to write_attribute
in Globalize3 which uses attribute_will_change! means we're storing
versions when there hasn't really been any change.
|
|\
| |
| |
| | |
'openaustralia_github/fix_search_highlight_non_ascii_characters' into rails-3-develop
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The connection to the database doesn't survive a fork, but can
be re-established if we disconnect beforehand, and use
establish_connection in the child after the fork.
rebuild_index with safe_rebuild=true is only called as a rake task
(i.e. in its own process) so this disconnection and reconnection
shouldn't affect the running of the site.
|
| |
| |
| |
| | |
This reverts commit b03451b6253b0c0ecd202b48f7a702b7e6844a90.
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Gemfile
Gemfile.lock
app/controllers/general_controller.rb
app/controllers/track_controller.rb
app/models/outgoing_message.rb
app/models/public_body.rb
app/models/user.rb
app/views/general/frontpage.rhtml
config/environment.rb
config/initializers/inflections.rb
config/initializers/mime_types.rb
db/migrate/094_remove_old_tags_foreign_key.rb
lib/timezone_fixes.rb
spec/models/request_mailer_spec.rb
spec/views/request/list.rhtml_spec.rb
|
| | |
|
| |\ |
|
| | |
| | |
| | |
| | | |
passenger rather than mongrel
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We do this by making strip_attributes manipulate the unsaved object so
that it doesn't interact with globalize3.
Calling 'record.attributes' would invoke the globalize3 overridden
method, which returns the stale translated attribute values.
We now use the object's values instead which are the ones we have just
assigned and want to update to.
|
| | | |
|
| | | |
|
|\ \ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
Conflicts:
Gemfile
Gemfile.lock
config/environment.rb
lib/i18n_fixes.rb
|
| |\| |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | | |
model specs pass
|
| | | |
|
| | | |
|
| | | |
|
| |/
|/| |
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Revert a small part of 33f8ef66084bbfb61bf0b4e0f53e1da5e7cc84dc,
which was not intended, so that the behaviour is unchanged if a
xapian database doesn’t exist, say.
|
|
|
|
|
|
| |
This *ought* to fix the problem with the alert-tracks daemon
opening more and more copies of the xapian db till it exhausts
the available file descriptors.
|
|
|
|
| |
Work (with subtly reduced resilience) on earlier versions.
|
|\
| |
| |
| |
| | |
Conflicts:
app/controllers/application_controller.rb
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Do not use FLAG_WILDCARD or FLAG_PARTIAL anywhere, because wildcard
searches can crash the whole server as per http://trac.xapian.org/ticket/350
(e.g. http://www.whatdotheyknow.com/body/search_ahead?query=app will
crash the server prior to this commit.)
This is a temporary fix while we investigate the possibilities of
the set_max_wildcard_expansion() method, which should make it possible
to alleviate this issue.
|
|/
|
|
|
|
|
|
|
|
|
| |
Wildcard searches in Xapian can expand uncontrollably, consuming
all available RAM and crashing the server. This has been a real
problem on WhatDoTheyKnow.com. The underlying issue is tracked
in http://trac.xapian.org/ticket/350
This changeset imposes a limit on wildcard expansion. The type-ahead
search will first try a wildcard query, and if that fails because
of too much expansion will fall back to a plain non-wildcard search.
|
|
|
|
| |
errors ad hoc as I find them that result from the workaround code. Fixes #328 (for good, I hope).
|
| |
|