Releases: palkan/logidze
1.3.0
Features
- Allow retrieving list of versions:
post.versions # => Enumerator
post.versions.find do
_1.title == "old title"
end
- Add
--after-trigger
option to generate after triggers for partitioned tables in older PostgreSQL versions.
Changes
This release requires Ruby 2.7+, Rails 6.0+, PostgreSQL 10.0+.
1.2.0
Features
- Add user-defined exception handling
By default, Logidze raises an exception which causes the entire transaction to fail.
To change this behavior, it's now possible to override logidze_capture_exception(error_data jsonb)
function.
Fixes
1.1.0
Features
- Added experimental pending upgrade checks support.
Now Logidze can check for a pending upgrade (e.g., when reinstalling Logidze functions is required).
Use Logidze.pending_upgrade = :warn
to be notified by warning, or Logidze.pending_upgrade = :error
if you want Logidze to raise an error.
Changes
- Logidze now only depends on
activerecord
andrailties
(so, adding Logidze to the project doesn't add all the Rails gems).
Fixes
- Stringify jsonb column values within snapshots (#171).
1.0.0
Features
- Added integration with
fx
gem.
Now it's possible to use Logidze with schema.rb
. Add fx
gem to the project, and new migrations will be
using Fx create_function
/ create_trigger
functions.
- Added
.with_full_snapshot
to add full snapshots to the log instead of diffs.
Useful in combination with .without_logging
: first, you perform multiple updates without logging, then
you do something like with_full_snapshot { record.touch }
to create a log entry with the current state.
- Added
#create_logidze_snapshot!
and.create_logidze_snapshot
methods.
Changes
- Refactored columns filtering.
Renamed --whitelist/--blacklist
to --only/--except
correspondingly.
The only-logic has been changed: previously we collected the list of columns to ignore at the migration generation time,
now we filter the columns within the trigger function (thus, schema changes do not affect the columns being tracked).
- Add
--name
option to model generator to specify the migration name.
When you update Logidze installation for a model multiple times, you might hit the DuplicateMigrationNameError
(see #167).
- Dropped support for Rails 4.2, Ruby 2.4 and PostgreSQL 9.5.
0.11.0
This release reverts some changes made in 0.10.0 related to ignore_log_data
functionality.
Changes
- Return
nil
whenlog_data
is not loaded instead of raising an exception.
We cannot distinguish between not loaded log_data
and not-yet-created (i.e. for new records).
The latter could be used in frameworks/gems (example).
- Only allow specifying
ignore_log_data
at boot time without runtime modifications.
Playing with ActiveRecord default scopes wasn't a good idea. We fallback to a more explicit way of telling AR
when to load or ignore the log_data
column.
This change removes Logidze.with_log_data
method.
0.10.0
Changes
- Ruby >= 2.4 is required
Features
- Added global configuration for
:ignore_log_data
option.
Now it's possible to avoid loading log_data
from the DB by default with
Logidze.ignore_log_data_by_default = true
In cases when ignore_log_data: false
is explicitly passed to the ignore_log_data
the default setting is being overriden. Also, it's possible to change it inside the block:
Logidze.with_log_data do
Post.find(params[:id]).log_data
end
PR #111
- Added
#reset_log_data
API to nullifylog_data
column.
Now you can reset the history for a record (or records):
# for single record
record.reset_log_data
# for relation
User.where(active: true).reset_log_data
PR #110
0.9.0
Features
- Added
#reload_log_data
to fetch the actuallog_data
from DB.
user = User.create!(params)
user.log_data #=> nil, 'cause it's generated DB-side
user.reload_log_data
user.log_data #=> Logidze::History
- Added
:ignore_log_data
option to#has_logidze
to avoid selectinglog_data
by default.
Usage:
class User < ActiveRecord::Base
has_logidze ignore_log_data: true
end
User.all #=> SELECT id, name FROM users
User.with_log_data #=> SELECT id, name, log_data FROM users
user = User.find(params[:id])
user.log_data #=> ActiveModel::MissingAttributeError
user.reload_log_data #=> Logidze::History
0.8.0
Features
Added ability to specify the debounce time to avoid spamming logs creation.
See PR #87.
Usage:
# 5000ms
rails generate logidze:model story --debounce_time=5000
You see the following in generated migration
CREATE TRIGGER logidze_on_stories
BEFORE UPDATE OR INSERT ON stories FOR EACH ROW
WHEN (coalesce(#{current_setting('logidze.disabled')}, '') <> 'on')
EXECUTE PROCEDURE logidze_logger(null, 'updated_at', null, 5000);
How to upgrade.
Please run rails generate logidze:install --update
to regenerate stored functions.
This feature checks if several logs came in within a debounce time period then only keep the latest one
by merging the latest in previous others.
The concept is similar to https://underscorejs.org/#debounce
without debounce_time
{
"h": [
{
"c": {
"content": "Content 1"
},
"v": 1,
"ts": 0
},
{
"c": {
"content": "content 2",
"active": true
},
"v": 2,
"ts": 100
},
{
"c": {
"content": "content 3",
},
"v": 3,
"ts": 101
}
],
"v": 3
}
with debounce_time
of 10ms
{
"h": [
{
"c": {
"content": "Content 1"
},
"v": 1,
"ts": 0
},
{
"c": {
"content": "content 3",
"active": true
},
"v": 2,
"ts": 101
}
],
"v": 3
}
0.7.0
Features
- Added support for storing meta information along with changes logs (PR #79)
Example:
Logidze.with_meta(ip: request.ip) { post.save }
puts post.meta # => { 'ip' => '95.66.157.226' }
This change requires Logidze DB functions upgrade:
rails generate logidze:install --update
rake db:migrate
This feature replaces the implementation of with_responsible
: now responsible_id
is stored inside the meta hash with the key _r
.
There is fallback to the old data structure ({ 'r' => 42 }
opposed to { 'm' => { '_r' => 42 } }
in the current implementation), so responsible_id
should work as usual for the existing data.
If you access the value manually (e.g. post.log_data.current_version.data['r']
), you have to add the fallback by yourself.
0.5.0: New features:
New features:
-
Associations versioning (experimental) wiki
-
Use timestamp (configurable) column as a source time for logs (PR)
Thanks to @charlie-wasp and @akxcv.