# Summary
Currently, there is no way to make optimization for a specific
database.
This commit is to give an approach to help developer use specific
database technique to do optimization.
For examples, the origin `update_descendants_with_new_ancestry` has a
lot of N+1 queries to update all descendants. By using
`regexp_replace` on Postgres, we can use one query to remove N+1.
I was going to change the way changed used the column name
in the update_cache_counter code. (the purpose of this branch)
Decided to roll that change back, but this test still looks good
all but one reference are updating the ancestor_ids column
This is a moot point to be honest, behind the scenes, it is just
updating the ancestors field in the database, but this gives us
some indirection so we can change the ancestor encoding scheme
Previously creating children in an after_* callback would cause the
child's ancestry column to contain just the parent id and not the entire
ancestry path.
A workaround was to call self.reload in the after_* callback, but this
commit makes the process work automatically.
The main issue looked to be that the child_ancestry method was using the
ancestry path before the save (using _was) which for new records was
obviously blank.
This revision uses the current value of the parent's ancestry, and adds
a child_ancestry_was method to return the old behaviour (with a more
descriptive name).
The change to update_descendants_with_new_ancestry was due to it relying
on the old behaviour. The revised version explicitly replaces the old
parent ancestry snippet (using child_ancestry_was) with the new one
path.
REVISED for 2.1.x version of ancestry
This logic is currently a redirect to the class level condition methods
anyway. So removing the indirection and just calling the class
methods directly
The class methods are defined by the scheme (e.g.: materialized path)
unscoped is making descendant_conditions tricky to remove
`parent` used to hold the node's `parent`. so it was called `parent`.
But now it holds the parent id.
So this PR renames the variable to ... `parent_id`
This section of code is too complicated to add the extra cognitive load
and have a confusing variable name
thanks @nicklamuro
it gets rid of a constant
it moves all the validation to one spot.
I'm thinking different strategies will have different schemes
I liked having it defined in materialized path, but wanted to get rid
of the constant more
- Problem
When the field field ancestry is an integer on database the method
`parse_ancestry_column` raise error because of split is not a method
of integer
- Solution
Return the method `to_s` on the method `parse_ancestry_column` to change
integer to string before do the split
- Error Log
```
NoMethodError:
undefined method `split' for 13654:Fixnum
# /home/klaus/.rvm/gems/ruby-2.3.1/gems/ancestry-3.0.7/lib/ancestry/instance_methods.rb:381:in `parse_ancestry_column'
# /home/klaus/.rvm/gems/ruby-2.3.1/gems/ancestry-3.0.7/lib/ancestry/instance_methods.rb:153:in `ancestor_ids'
```
- Issue: #446
Keenan Brock
Michael Moll
Michael Yagudaev
Minh Nguyen-Hue
Daniel Tamai
Jason Stirk
d-m-u
Denny Mueller
Allan Klaus
David Staehler