Compatibility with Rails 8.1 #435

t27duck · 2025-10-03T13:13:59Z

Handle cast_type being the second parameter for SpatialColumn.initialize.
Handle nil case during OID initiation.
Handle case where in spatial_factory the object could be frozen for whatever reason.
Update CI to test against 8.1 and supported postgresql versions.

These changes require the changes from rgeo/rgeo-activerecord#83 so that gem is set to pull from the repo in this branch.

At least locally, there are 5 failures and 2 errors in the test suite with these changes. The failures are all in the deprecation tests and the errors are related to connection tests (I think).

I've been running both this branch and the changes to rgeo-activerecord in an app for several weeks with no issue, though granted the app only really cares about storing and retrieving geometry data with minimal to no querying.

If nothing else, here's a good starting point.

t27duck · 2025-10-03T13:14:46Z

lib/active_record/connection_adapters/postgis/oid/spatial.rb

          #   has_z:    false
          #   has_m:    false
          def self.parse_sql_type(sql_type)
+            # Could be nil during type registration


Not entirely sure why this happens as I'm not fully familiar with active record internals, but this seems to work.

I'm investigating it these days on crdb adapter, I hope I'll come with more information and a clean solution soonish :) (before the end of this month)

t27duck · 2025-10-03T13:15:25Z

lib/active_record/connection_adapters/postgis/oid/spatial.rb


          def spatial_factory
-            @spatial_factory ||=
+            if frozen?


Debated on this branch for a bit, not sure when this object would be unfrozen now.

I think we should see if there is a performance a space change, but I'd rather bubble that back up to the initialiser than create a factory every time. Also the if frozen? branch is useless since the goal of ractor compatibility for types as I understood is to have them frozen all the time !

seuros · 2025-10-05T09:22:16Z

There are more changed required to have the adapter working.

For this reason, i decided to create an extension instead of legacy way of having a pg adapter..

My goal is to move that repo later to this organization. The interface is plug & play.

t27duck · 2025-10-05T21:12:48Z

Actually looking at the failed tests, they seem to all be from the ActiveRecord test suite itself. Is there a reason why the gem runs the tests for Rails?

seuros · 2025-10-15T13:34:09Z

let upgrade to test with rc1

- Handle `cast_type` being the second parameter for `SpatialColumn.initialize`. - Handle nil case during OID initiation. - Handle case where in `spatial_factory` the object could be frozen for whatever reason. - Update CI to test against 8.1 and supported PG and Rubies.

seuros · 2025-10-15T18:55:48Z

Gemfile

 gem "pg", "~> 1.0", platform: :ruby
 gem "byebug" if ENV["BYEBUG"]

+gem "rgeo-activerecord", git: "https://github.com/rgeo/rgeo-activerecord.git"


interesting!

Do rgeo need any release ?

Yes, I had a PR for 8.1 support merged a few weeks ago..

On it now ! Thank you for the PR

BuonOmo · 2025-10-17T16:36:18Z

The failures are all in the deprecation tests

I found a solution for that in the 8.1 crdb adapter update cockroachdb/activerecord-cockroachdb-adapter@e656a24.

Actually looking at the failed tests, they seem to all be from the ActiveRecord test suite itself. Is there a reason why the gem runs the tests for Rails?

Running rails test suite ensure a complete coverage that we would not have with only our own test suite, and helps us make sure that we implement all API changes from the rails release we are bumping to

Borrowed from cockroachdb/activerecord-cockroachdb-adapter@e656a24#diff-ce5c7fbac7d9135b5da3cda2f2a9a00e930ce097624d919ef81100dca118e31d

t27duck · 2025-10-18T22:28:26Z

Current state of things:

Locally, tests should pass now with the inclusion of those backtrace fixes.

I removed the frozen? check in #spatial_factory.

I tried moving that logic into the initializer, but ran into two issues:

geo_type could be nil (probably a result of that nil check in .parse_sql_type.
After casting geo_type as a string always, the remaining failing test is ActiveRecord checking if the object is safe for ractors, which it wasn't with the change.

t27duck · 2025-10-19T20:29:42Z

Looks like the runners that failed all failed on the same error.

  1) Error:
CounterCacheTest#test_reset_counters_for_multiple_records:
ActiveRecord::Fixture::FixtureError: table "dogs" has no columns named "trainer_id", "dog_lover_id".

Which is an ActiveRecord test for fixtures. Possibly a flakey test?

modosc · 2025-10-29T17:00:17Z

.github/workflows/tests.yml

        ruby: ["3.4", "3.3", "3.2"]
        # https://www.postgresql.org/support/versioning/
-        pg: [12-master, 13-master, 14-master, 15-master, 16-master]
+        pg: [13-master, 14-master, 15-master, 16-master, 17-master]


~~pg 18 was released a month ago is there a reason not to include it here?~~ my fault, this pr went up before it came out. still might be nice to add here though.

gap777 · 2025-11-05T21:05:29Z

I'm a little confused... @t27duck is the path forward to adopt the new gem that @seuros is proposing (whereby the pg adapter is extended rather than replaced), or to bring in Rails 8.1 compatibility with this gem?

We're blocked on our upgrade and would love assistance/guidance on where to go with this issue.

BuonOmo · 2025-11-05T22:19:12Z

@gap777

whereby the pg adapter is extended rather than replaced

This plan has not been discussed by maintainers of the gem, you'd have to ask @seuros. As far as I'm concern, I'd rather keep this gem.

I'm currently working on rails compatibility for the CRDB adapter, once done I'll have time to handle this more properly. In the mean time, you can point to this branch. The differences are usually in some deep functionnalities and you're unlikely to have problems. And if you do, please report them here.

We're blocked on our upgrade and would love assistance/guidance on where to go with this issue.

You can talk to your company about RGeo's open-collective and financing. Or directly hire me as a freelance if you need fast-paced guidance and proper deadlines. Otherwise, as we're few to maintain on our spare time, I cannot give you deadlines.

seuros · 2025-11-06T13:39:11Z

@BuonOmo Actually i did send email to both you and @keithdoggett in 2024 i think. I did have a back and forth with Keith. My plan was to create it and transfer it to this org.

I assumed you were in the same line as what Keith said, to keep this architecture.

activerecord-postgis-adapter is an inherited adapter. I contributed to it when It was just basically a copy carbon the upstream adapter. I did raise my concern that one day it will be good have it extending AR instead of forking.

activerecord-postgis is that wish but as reality, different archirecture, same api. I had that gem vendored for my needs since rails 7.0. but it had no README and was missing feature i didn't use.

I contributed to this adapter, because i knew upgrade it, not because i needed the upgrade.

When i released activerecord-postgis, i posted it in reddit, X, HN, and i got immediately hammered by Anti-AI people telling me that i vibed it and that it not how it should be made.

They didn't try it or reviewed the code. They see Claude and emojis in readme... They went full tribal ape on me.

The moderators deleted the post after it went -40 and subject became about AI slop.

My tweet still up, but with minimal engagement.

activerecord-postgis is the exact copy of this gem(api-wise), the underline Activerecord logic is from rgeo org.

BuonOmo · 2025-11-06T15:53:18Z

@BuonOmo Actually i did send email to both you and @keithdoggett in 2024 i think

Never received it sorry, do you have the correct email ? buonomo dot ulysse at gmail dot com.

My plan was to create it and transfer it to this org.

No-go for me, we're not a team large enough to handle such a transition, see all of the open issues and the time to upgrade to rails 8.1 as an indicator. I'm not taking one more project. I'd eventually be alright with mentioning it as an existing alternative in the README, if it is not a drop-and-replace but an alternative for a different use case.

activerecord-postgis-adapter is an inherited adapter. I contributed to it when It was just basically a copy carbon the upstream adapter. I did raise my concern that one day it will be good have it extending AR instead of forking.

I have a hard time understanding your point here. We already extend the PG adapter, which IMHO is a pretty correct way of doing. We don't copy, and I tend to try to patch rather than copy paste methods as much as I can, and would like to keep going in that direction.

When i released activerecord-postgis, i posted it in reddit, X, HN, and i got immediately hammered by Anti-AI people telling me that i vibed it and that it not how it should be made.

You posted what?

The moderators deleted the post after it went -40 and subject became about AI slop.

Which post? About what topic?

I have a bit of a tough time understanding the problems you are raising and how those are linked to your new gems.

They didn't try it or reviewed the code. They see Claude and emojis in readme... They went full tribal ape on me.

Damn that's not cool. I really hope we can work out something that work for you as well. I'm all up for having a bigger team here, with better organisation.

seuros · 2025-11-07T04:22:01Z

Yes, the email was correct, but I suspect it went to spam. Keith did receive it.
I figured out that will be situation, that’s why I didn’t try to push it without total agreement.

The alternative gem is a 99% drop-in replacement. The only difference is in annotation output and the use of postgresql:// instead of postgis://. (If you replace it and don’t fix the adapter or DATABASE_URL, it will crash.)
API-wise, it’s identical.

My point is that I’ve been involved with this gem since the days when dazuma (the original author) was still maintaining it.
Back then, the only way to have an adapter was to copy it, since Rails’ codebase wasn’t ready.

Then came another era with Tee Perham, and we did a big refactor to inherit from the adapter, renamed columns to avoid conflicts with PostgreSQL internal types once Active Record started using them, that’s the current structure of this gem.
Finally, with Rails 7.0, it became possible to add types the same way I do with the other gem, the architecture changed, and Rails introduced multi-DB support.

You posted what?
Which post? About what topic?
I have a bit of a tough time understanding the problems you’re raising and how those are linked to your new gems.

I posted about the other gem in social media 'Announcing activerecord-postgis, a drop-in replacement...'
The reaction was negative right away. One commenter accused me of trying to publish AI slop and said I stole RGeo’s work by not forking instead.
It’s 2025: people react. They didn’t read the README to see that the acknowledgments.

It got immediate downvotes and insults by email. (Most of them don’t even use Postgres or know what a spatial database is... maybe they thought I forked NASA or SpaceX.)

I’m fine with just having a mention in the README for now. But my goal is for the other gem to eventually take this one’s place.

I can maintain it, it’s smaller, cleaner, and has more tests.

My only concern with solo maintenance is that it might work fine for my use case but break for others.

Just to give you an example: before open-sourcing it, I had a hardcoded SRID. That works when I control the architecture, but I can’t open-source it and force everyone to use a single SRID.

We need to get this PR green to ship.

seuros

Checked locally, the failure are just timing related.

BuonOmo · 2025-11-07T17:14:57Z

Yes, the email was correct, but I suspect it went to spam. Keith did receive it.

I just checked again for the keywords "seuros", "activerecord", and "postgis" within my whole mailbox + spam, nothing :/

My only concern with solo maintenance is that it might work fine for my use case but break for others.

My other concern would also be that the day you decide to stop working on it, the whole community loses the gem... At least here we're two maintainers, and a few active developers.

I can maintain it, it’s smaller, cleaner, and has more tests.

Could you maybe make an issue in this repo explaining the main axes of differences and how we could refactor to get to an ideal place that keeps steps made here, history and still take advantage of the new rails architecture?

Checked locally, the failure are just timing related.

What do you mean? I believe there is still the ractor issue that we need to either tackle or create an issue for. And about the failing tests, if by timing you mean that they depend on test order, that is still not green IMHO. I've been using minitest-bisect with the crdb adapter for that purpose. I'll be able to do it here as well once I've shipped the crdb adapter. Otherwise, feel free to do it :)

EDIT:

I've also taken the time to look at your new adapter, and I see two main issues that make it a no go for me:

it modifies in-place the postgresql adapter. I'm not sure the quantity of users having this issue but you could have two dbs been both pg and postgis. Which would not work with this adapter
it doesn't make use of the (geometry|geography)_column from postgis which makes me wonder about performance diff. Do you have a plan to check performances ?

I'm not done with the review, this is quite a heavy chunk. But I can see the pieces we could migrate to this codebase, which would be nice.

seuros · 2025-11-07T18:10:14Z

My other concern would also be that the day you decide to stop working on it, the whole community loses the gem... At least here we're two maintainers, and a few active developers.

That exactly why i asked it to move it to https://github.com/rgeo/activerecord-postgis instead. Was not asking to have traffic send to my repo while keeping the gem.

I use the gem heavily, i did not see any regression.

BuonOmo · 2025-11-08T16:40:17Z

I use the gem heavily, I did not see any regression.

Then users can point to this branch with some sense of security. I would still focus on fixing tests and make sure ractor compatibility is correct. I would be okay with having an 8-1 branch that people can point to until we are ready for a release, if any interest?

That exactly why I asked it to move it to https://github.com/rgeo/activerecord-postgis instead. Was not asking to have traffic send to my repo while keeping the gem.

Well, I'm up to opening PRs here to migrate some parts of your code (for instance the arel part, but I'm sure you know of others that would make sense). I still am against patching pg adapter and think we should rather inherit (as mentioned above), but that could be up for discussion.

t27duck commented Oct 3, 2025

View reviewed changes

t27duck force-pushed the allow_rails81 branch from 5f6e071 to 6b0af9e Compare October 15, 2025 18:31

t27duck changed the title ~~Compatibility with Rails 8.1.beta1~~ Compatibility with Rails 8.1 Oct 15, 2025

seuros reviewed Oct 16, 2025

View reviewed changes

t27duck added 2 commits October 18, 2025 18:20

Fix backtrace in deprication tests

0710889

Borrowed from cockroachdb/activerecord-cockroachdb-adapter@e656a24#diff-ce5c7fbac7d9135b5da3cda2f2a9a00e930ce097624d919ef81100dca118e31d

Remove pointless frozen check logic

b0041ea

Update gemspec for Rails 8.1.0 final

4a4faf5

modosc reviewed Oct 29, 2025

View reviewed changes

seuros approved these changes Nov 7, 2025

View reviewed changes

Uh oh!

Compatibility with Rails 8.1 #435

Are you sure you want to change the base?

Compatibility with Rails 8.1 #435

Conversation

t27duck commented Oct 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

t27duck Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

BuonOmo Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

t27duck Oct 3, 2025

Choose a reason for hiding this comment

Uh oh!

BuonOmo Oct 17, 2025

Choose a reason for hiding this comment

Uh oh!

seuros commented Oct 5, 2025

Uh oh!

t27duck commented Oct 5, 2025

Uh oh!

seuros commented Oct 15, 2025

Uh oh!

seuros Oct 15, 2025

Choose a reason for hiding this comment

Uh oh!

t27duck Oct 16, 2025

Choose a reason for hiding this comment

Uh oh!

BuonOmo Oct 17, 2025

Choose a reason for hiding this comment

Uh oh!

BuonOmo commented Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

t27duck commented Oct 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

t27duck commented Oct 19, 2025

Uh oh!

modosc Oct 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gap777 commented Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

BuonOmo commented Nov 5, 2025

Uh oh!

seuros commented Nov 6, 2025

Uh oh!

BuonOmo commented Nov 6, 2025

Uh oh!

seuros commented Nov 7, 2025

Uh oh!

seuros left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

BuonOmo commented Nov 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

seuros commented Nov 7, 2025

Uh oh!

BuonOmo commented Nov 8, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

t27duck commented Oct 3, 2025 •

edited

Loading

BuonOmo Oct 17, 2025 •

edited

Loading

BuonOmo commented Oct 17, 2025 •

edited

Loading

t27duck commented Oct 18, 2025 •

edited

Loading

modosc Oct 29, 2025 •

edited

Loading

gap777 commented Nov 5, 2025 •

edited

Loading

seuros left a comment •

edited

Loading

BuonOmo commented Nov 7, 2025 •

edited

Loading