Upsert 3.0.0

[pnomolos]

Meta-issue to track everything for the Upsert 3.0.0 release.

• Fix issues with Ruby 2.6 (Upgrade to Ruby 2.3/ActiveRecord 5 as a minimum #105, Updates to be compatible with Ruby 2.6 #115)
• Travis - Remove old versions and add newer versions (Updates to be compatible with Ruby 2.6 #115, Bump development Ruby version to 2.5 #116)
• Have a better DB matrix using docker images (Preferred would be all currently supported variants of major databases that we support - so Postgresql, Mysql, Maria, and SQLite3) (Improve, update, and optimize the travis setup #118)
• Convert to standardrb
• Better documentation (add installation instructions for rails #94, Gotcha postgres: unique_index_on_selector? does not work as expected #111, Upsert 3.0.0 #117 (comment))
• Be able to fully address schemas (Cannot update table within a schema (Postgres) #53, [WIP] Initial work on fully qualified (schema/db) addressing. #104)

[pnomolos]

To anyone using this gem, I'm trying to limit 3.0.0 to getting the gem working on modern versions of Ruby/JRuby and pulling in a few outstanding API-breaking tickets (As well as a few documentation updates).

Is there anything else that would be a breaking change and is a major blocker that you'd like to see in 3.0.0?

/cc @seamusabshere @olivierlacan @KevinColemanInc @searls

[KevinColemanInc]

I am currently not using the gem, so I don't have any input to give.

[pnomolos]

I am currently not using the gem, so I don't have any input to give.

@KevinColemanInc Anything that's blocking you from using it that could be added in a future update, or do you just not need it currently?

[searls]

Other than getting working on the latest everythings, my only feature request would be some way to remove old/unnecessary upsert-generated pgsql functions. I have a bunch of these lingering in my production database even though I've since adjusted things such that they're not being needed

[pnomolos]

Other than getting working on the latest everythings, my only feature request would be some way to remove old/unnecessary upsert-generated pgsql functions. I have a bunch of these lingering in my production database even though I've since adjusted things such that they're not being needed

@searls Would a note in the README suffice, or do you think it should be built in to the library? I currently do the following:

    Upsert::MergeFunction::NAME_PREFIX = "upsert"
    DB.synchronize do |conn|
      Upsert.clear_database_functions(conn)
    end

[searls]

Honestly, whether it cleans up after itself automatically or you just document it—entirely up to you! Literally the only pain/friction I can point to

[KevinColemanInc]

do you just not need it currently?

I just don't need it currently

[searls]

Found a thing I'd love in a new version! #120

[searls]

Mind cutting a release with where things are? I've been running off a github fork for the last month

[pnomolos]

@searls I’ll be wrapping this up and cutting a release when I’m back in a couple weeks. Sorry for the big delay!

[pnomolos]

@searls @olivierlacan I've cut a 2.9.9 release that's effectively 3.0.0 except there's one small bug with jruby that I'm still ironing out.

[sgeef]

@pnomolos I'm unsure on the exact details of the issue I'm seeing, but currently investigating it.

I've upgraded from v2.2.1 to the current latest. and started having issues with a not nullable field, which is not in the setter nor on the selecter and before the update didn't break.. I'll keep you posted, while I investigate, but would you have any idea where this might be related too?

Note, we are forced to get the latest versions to get to v12 off postgres.

[pnomolos]

@sgeef Have you cleared all your upsert functions since the update? I use the following for Sequel:

Upsert::MergeFunction::NAME_PREFIX = "upsert"
DB.synchronize do |conn|
  Upsert.clear_database_functions(conn)
end

run this in a one-off, the big takeaway is to redefine the merge function prefix so it clears everything.

[sgeef]

@pnomolos this doesn't seem to be the issue. as our test suite doesn't have the functions by default and are re-generated by default.. So I guess there is another breaking changing, somewhere since v2.2.1

After debugging both the old version and the new version I've figured that the v2.2.1 returned on the use_pg_native? method false before and now started returning true.

Which was related to the unique_index_on_selector?, which before seems to have had a bug (#111). At least now it returns correctly that it has a unique index.

But we now are not based on functions anymore, but straight on the pg_native approach. Which, if it has a not-null field on the insert, not having a value and not being provided, off course will fail.

I'll try to fix this on our side, by providing the correct default value to the non-null column. Thanks for the tip on the clearing of the functions.

[sgeef]

Just to leave this closed @pnomolos, thanks for helping out. it turned out we only need updates, which explained why it didn't ever fail with the function.. It seems though that the native approach fails if you lack a non-nullable field.. as the insert would never be able to execute. (Solved!)