release next version

[kbrock]

• [x] https://github.com/stefankroes/ancestry/pull/607
• [x] double check if #589 introduced something bad
• [x] update the changelog
• [x] Enable test for hooks_test.rb:35 -- punt. will do later

[kbrock]

probably definitely not for this release

In the future, possibly setup config for the following:

• set materializedpath2 as the default
• no self returned from siblings
  • alternative: self.siblings.without(self)
  • look at how other gems name this. one example: siblings_with_self
• introduce gemspec.post_install_message warning that you need to set these configs for upgrades
• no siblings returned from roots.first

updated

[kshnurov]

Well, the main branch is already at 4.3 with a proper changelog. All you need it to update RubyGems.

601 is just a README change, nothing to release here.

materializedpath2 is the default - I agree, but it should be a major version bump.

[kshnurov]

It started as ascii varchar, and prefer to get it as close to the original field as possible. But I would like to document the binary case that you mention. I would like that case better if the sql generated were text and not escaped binary. Want to change mysql to a binary column. (character set=ascii would be preferable but just too hard)

I guess you should just read about database collations/character sets, what they do and when they are needed. This gem doesn't need ascii, C, latin or whatever collation there is. binary is all that's needed, it's faster and takes less space.

[kshnurov]

no self returned from siblings

Why? It would be a very simple, but breaking change. Whoever needs that, should just do self.siblings.without(self), that'll produce a proper SQL.

[kshnurov]

track down test disabled for postgres extension. Thought it was for update_descendants_after_update. I possibly already fixed this. can't find it

It's this one. I'm strictly against this SQL strategy anyway, there's nothing good in skipping all Rails callbacks. It's not even updating the updated_at - cache won't be invalidated. Btw, have no idea why the README says it's PG only, should also work with MySQL.

[kbrock]

re #601: In postgres, binary seems to use indexes better than the collation mode. So this is an improvement. But the sql generated is hard to read:

SELECT "users".* FROM "users" WHERE ("users"."ancestry" LIKE '\x383737362f25' OR "users"."ancestry" = '\x38373736')