riboseinc / activeid Goto Github PK

@skalee could you please help fix the GHA builds?

And update the GHA config with the previous Travis matrix. Maybe we should combine the workflow files for the same matrix... Up to you. Thanks!

-  - jruby
-
-gemfile:
-  - gemfiles/Rails-5_2.gemfile
-
-env:
-  - DB=sqlite3
-  - DB=mysql
-  - DB=postgresql
-
-matrix:
-  include:
-    - gemfile: gemfiles/Rails-head.gemfile
-      env: DB=sqlite3
-    - gemfile: gemfiles/Rails-head.gemfile
-      env: DB=mysql
-    - gemfile: gemfiles/Rails-head.gemfile
-      env: DB=postgresql
-    - gemfile: gemfiles/Rails-5_1.gemfile
-      env: DB=sqlite3
-    - gemfile: gemfiles/Rails-5_1.gemfile
-      env: DB=mysql
-    - gemfile: gemfiles/Rails-5_1.gemfile
-      env: DB=postgresql
-    - gemfile: gemfiles/Rails-5_0.gemfile
-      env: DB=sqlite3
-    - gemfile: gemfiles/Rails-5_0.gemfile
-      env: DB=mysql
-    - gemfile: gemfiles/Rails-5_0.gemfile
-      env: DB=postgresql
-    # Without monkey patches
-    - env: DB=sqlite3 NO_PATCHES=1
-    - env: DB=mysql NO_PATCHES=1
-    - env: DB=postgresql NO_PATCHES=1
-  allow_failures:
-    - gemfile: gemfiles/Rails-head.gemfile
-    - rvm: jruby

Originally posted by @ronaldtse in #60 (comment)

In Rails 5.1, fields labeled t.uuid or the id field on classes that have include ActiveUUID::UUID no longer return a UUIDTools::UUID instance, instead returning a string encoded as "ASCII-8BIT", which corresponds to calling .raw on a UUIDTools::UUID instance returned by the regular behavior.

E.g. in Rails 5.1

MyModel.first.id
=> "$A\xBBa\xA5^MO\xB1\r\xAC\x95e\x12\x8A\xE6"

Old behavior in Rails 5.0 and below

MyModel.first.id
=> #<UUID:0x2b0cfcee945c UUID:2441bb61-a55e-4d4f-b10d-ac9565128ae6>
MyModel.first.id.raw
=> "$A\xBBa\xA5^MO\xB1\r\xAC\x95e\x12\x8A\xE6"

For example: https://github.com/riboseinc/activeid/runs/729980124?check_suite_focus=true.

• Make sure that modules are renamed everywhere.
• Make sure that README is updated.
• Reset version number (possibly to 1.0).
• Push to RubyGems.

As title.

@kwkwan please help provide additional information. Thanks!

For @HassanAkbar

This gem is forked from https://github.com/jlsookiki/activeuuid which is a fork of https://github.com/inbeom/activeuuid which is a fork of https://github.com/jashmenn/activeuuid. The last one is an original source, but the most recent commit on master is from 2 Sep 2015, also 10 pull requests are open and not merged in. On the other hand, the original author is still active on GitHub, and was commenting these pull requests in 2017. But again, his comments from August are like he is willing to add more collaborators to activeuuid project, and even allow them to push new versions to RubyGems.

In these circumstances, a couple of questions rise:

1. Do we plan to create pull requests in the original repository, and perhaps ask for contributor privileges? Or continue maintaining activeuuid in riboseinc/activeuuid?
2. If the latter, do we want to release gem to RubyGems under new name? Then what name? activeuuid_riboseinc, perhaps?

For example: https://github.com/riboseinc/activeid/runs/729980157?check_suite_focus=true.

Binaries in database logs are difficult to read. When working with MySQL backend, we should consider replacing explicit binaries with UUID_TO_BIN('human-readable-uuid')andBIN_TO_UUID` function calls.

See:

• https://mysqlserverteam.com/mysql-8-0-uuid-support/
• https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_uuid-to-bin
• https://dev.mysql.com/doc/refman/8.0/en/miscellaneous-functions.html#function_bin-to-uuid

Unfortunately, MariaDB does not provide such functions yet. See:

• https://jira.mariadb.org/browse/MDEV-15854

It seems that there are literally no tests which prove its correctness… Otherwise, #55 would never be requested.

Current API is quite limited and clumsy. Although it supports generation of version 1, 4, and 5 UUIDs (which is perfectly enough), it is done with three methods, which makes things less clear. Furthermore, only primary key UUIDs can be autogenerated this way (though I am not yet sure whether it is an issue or not).

At the moment, this gem's Travis build matrix is a Cartesian product of Ruby versions, Rails versions, and database backends. 54 build jobs in total, and certainly more in future. This should be simplified.

I was thinking about it for quite some time, but there were problems on Travis AFAIR. Perhaps in GHA it will work.

Although Ruby 2.3 has reached its end of life, this gem is compatible in general, just tests fail due to some issues with mysql2 gem.

This should be easy to fix, and perhaps downgrading mysql2 gem will suffice. If I'm wrong, then perhaps it's best to drop support for that outdated Ruby version. At the time of writing this, the gem has been just renamed and hasn't been pushed to Rubygems since that yet, so it's a very good moment for incompatible changes.

Let's cut off some ballast. Legacy code means trouble.

There's no point in reintroducing Rails 4.2 support. Although it still receives occasional security updates (May 2020), it's really old and two major versions behind the latest Rails.

Let's drop support for some oldest Rubies too. There is no point in maintaining compatibility with Ruby 2.3, which has reached its end of life over a year ago (on 2019-03-31), and is causing problems due to incompatibility with current versions of mysql2 gem. We should drop support for Ruby 2.4 too — although it isn't problematic now,

There is no good point in maintaining compatibility with Ruby 2.4, which has reached its end of life about two months ago (2020-03-31). Although all works now, we can expect some problems in future, especially with native code in database backends.

Perhaps we should drop support for Ruby 2.5 too, I haven't decided yet. It is still supported, but fairly old and is scheduled to reach its end of life next year (on 2021-03-31). Dropping support now means not having to do it in near future. It's good to do one big breaking change rather than two smaller ones.

TODO

• Remove old versions from test matrix.
• Remove any logic which was for Rails 4 solely.
• Remove any logic which was for older Rubies solely.
• Remove support for mysql gem (not to be confused with mysql2)
• Bump Ruby and Rails version constraints in the gemspec.
• Update tools configuration (e.g. Rubocop)
• Mention in the README that the original gem supports older software.

For some reason, Travis is complaining about gem "pg" not being included and whatnot:

Add `gem 'pg'` to your Gemfile (and ensure its version is at the minimum required by ActiveRecord). (Gem::LoadError)

For example: https://travis-ci.org/riboseinc/activeuuid/jobs/338812989

I tried adding require "pg" (d2e4517) in different places (4d4daae) but it would still complain about the same thing. As such, I've put the env: DB=postgres line under allow_failures: in .travis.yml (81fde57) just to let Travis turn green.

Any idea on how to approach this problem?

cc: @skalee

When run under Rails 5.1, the following deprecation message would show:

DEPRECATION WARNING: Defining #quoted_id is deprecated and will be ignored in Rails 5.2. (defined on UUIDTools::UUID at /src/activeuuid/lib/activeuuid/uuid.rb:19) (called from quote at /src/activeuuid/lib/activeuuid/patches.rb:130)

There are quite a few instances of #quoted_id being called and defined in the code, and they should all be removed.

Related:

rails/rails#27962

As title. This is why we're keep having problems, and we should make sure stuff doesn't break again.

@skalee perhaps you could help? Thanks!

I have two tables - User and Devices:

class User < ActiveRecord::Base
  include ActiveUUID::Model
  attribute :id, :uuid
  has_many :devices
end
class Device < ActiveRecord::Base
  include ActiveUUID::Model
  attribute :id, :uuid
  belongs_to :user
end

uuid is registered as ActiveUUID::Type::BinaryUUID
when I try to create these in DB

user = User.new
user.save!
device = Device.new
device.user = user
device.save!

I get a SQL error:

INSERT INTO `users` (`id`) VALUES (x'f33f3538371c4ba78715819dd972e4bf')
ActiveRecord::ValueTooLong: Mysql2::Error: Data too long for column 'user_id' at row 1: INSERT INTO `devices` (`id`, `user_id`) VALUES (x'2ae9bccb22774b35add0d8673bce282e', x'66333366333533382d333731632d346261372d383731352d383139646439373265346266')

if I decode the hex string x'66333366333533382d333731632d346261372d383731352d383139646439373265346266' I get 'f33f3538-371c-4ba7-8715-819dd972e4bf' - and it looks like id of the user

In case of UUIDs version 1 (timestamp-based ones), a major performance boost can be achieved by rearranging bits. See https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ for clarification and experimental proof.

This feature is highly desired, but will break compatibility with legacy versions of activeuuid. For this reason, it must be optional, and disabled by default.

As title.

Builds are broken for Rails 5.2 due to a missing method ActiveRecord::Migrator.migrate. Similar issue in other project: thiagopradi/octopus#477.

Tests are currently failing in Travis CI when they are run against ruby-head.

related to #57

As this is different from the behaviour of the original gem, it helps to clarify that all UUID columns have to be explicitly declared in the model.

Something like adding a NOTE: under Adding UUIDs to models may suffice.

Attributes API has been changed significantly in Rails 5.0, and current implementation is not compatible with Rails 4.2. Fixing it is not trivial (see this build for details), though certainly doable. However, given the fact that people on Rails 4.2 should upgrade anyway, and that they also can use the original gem, I do not see much value in this improvement. Nevertheless, I am going to keep this issue open here in case someone wants to contribute.