Support for Rails 8.0.0

[navidemad]

Thanks for the awesome gem.
I recently migrated my app to Rails 8.0.0.beta1, and wanted to try this adapter but there is a lock becase activerecord-postgis-adapter >= 9.0.0 depends on activerecord ~> 7.1.0.
Looking forward to test it :)

[BuonOmo]

Hi @navidemad

I don't think we'll do such a thing, as we are still trying to find time to handle 7.2 (non-beta) support. If you want to be the champion of it, or if you find a way to sponsor the gem (https://opencollective.com/rgeo), then this may happen :)

We'll for sure take care of it when it goes out of beta (I'm also paid maintainer of the activerecord-cockroachdb-adapter, hence I usually first upgrade there, and then here)

[formigarafa]

I've been looking around and trying to help but I am a bit confused because of the current state of master(or main) branch.
There is #397 merged titled "feat!: ActiveRecord 7.2 support". There are some issues and PRs mentioning something around jRuby which I could not understand what is the decision moving forward. Others talking about specs breaking but only in CI.
And I could not figure what is related to 7.2 or what exactly is breaking.
I noticed that in the history of the project people have used some labels for active record versions. It might be helpful having some of these labels applied for engaging the community.
If I could see some direction, steps, checklist,... but I couldn't figure what is needed.

[BuonOmo]

@formigarafa currently we have only partial support of the beta, and I have a PR ongoing for full support, but tests are failing (#405).

So the current goal is merging #405, which I'm considering to merge with some tests ignored and opening related issues. If that is the case would you be able to help on fixing tests (and thus maybe some parts of the codebase as well...).

About JRuby support, we're not really supporting it with new rails versions, I think @seuros knows why. But anyway, we should already focus on having the main C ruby up before thinking jruby!

[seuros]

Currently, we do not support JRuby because the latest version of the gem only supports a single version of ActiveRecord (7.2.x).

Unlike CRuby, JRuby does not use the pg gem but relies on a Java-compliant adapter. As shown in the matrix above, the latest supported version is Rails 7.1.x, which is an unreleased version and has a few issues in the tracker.

I believe we could add JRuby support once it is accompanied by appropriate tests. The last version of this gem that I have personally tested is with Rails 6.x.

[formigarafa]

That clarify heaps, thanks. I was wondering if jRuby compatibility was a blocker. If that isn't the case, I agree with @BuonOmo, just focus on what is supported in first place should be the best for everyone. Even better with a single PR to look at. Thanks.

[matthee]

Rails 8.0.0 has been released a few days ago. Maybe update the title to "Support for Rails 8.0.0" and reconsider the "won't fix" tag?

[BuonOmo]

@matthee fair enough.

This doesn't mean that we magically have time to push it forward now! I suspect @keithdoggett is quite busy these days, and I have to earn some money myself as well. As I said in the related PR:

• If you want fast upgrade you can point to @StoneGod's branch.
• If you want accurate and fast upgrade, we can discuss timing and pricing by email! (see my Github profile)

[matthee]

Thank you for updating the issue!

I know and appreciate that supporting this gem is a lot of work for you maintainers. I just wanted to keep this issue moving forward. 😉

[tomas-stefano]

Hi all,

First, a big thank you for this amazing gem.

Sorry if I am off-topic but I'd like to ask extra advice.

My Rails app is using Rails 8, and while I’m aware the adapter doesn’t officially support it yet, I’ve been exploring ways to keep things running smoothly - in the meantime the gem doesn't support Rails 8.

Out of necessity, I’ve been working without the adapter, but I’ve hit a few challenges that I’d love advice on.

Specifically, I’ve encountered issues with the internal tables PostGIS uses for geospatial calculations when recreating the database. Running the usual setup commands:

rails db:drop db:create db:schema:load db:migrate

leads to this error:

PG::DependentObjectsStillExist: ERROR:  cannot drop table spatial_ref_sys because extension postgis requires it

To work around this, I added the following initializer to ignore spatial_ref_sys during schema dumps:

ActiveRecord::SchemaDumper.ignore_tables |= ["spatial_ref_sys"]

However, this workaround introduced another issue during testing. Without properly handling spatial_ref_sys, tests would fail with:

ActiveRecord::StatementInvalid:
       PG::InternalError: ERROR:  Cannot find SRID (4326) in spatial_ref_sys

To address this, I added a before(:suite) configuration in the test setup:

config.before(:suite) do
  postgis_table_count = ActiveRecord::Base.connection.execute(                                                                                                                           
    "SELECT COUNT(*) FROM spatial_ref_sys WHERE srid = 4326;"                      
  ).values.flatten.first.to_i                                                      
                                                                                     
  if postgis_table_count.zero? 
    # Force the extension to re-create everything needed                                                    
    ActiveRecord::Base.connection.execute("DROP EXTENSION IF EXISTS postgis CASCADE;")
    ActiveRecord::Base.connection.execute("CREATE EXTENSION IF NOT EXISTS postgis;")
  end
end

This makes sure the table is in place, but it feels more like a patch (a.k.a "workaround") than a robust solution.

Given this context, I’d love to ask:

1. Are there any extra tips for making PostGIS work smoothly in Rails 8 without the adapter?
2. Are these workarounds reasonable, or could they cause unexpected side effects I should be mindful of?
3. When enabling the extension without adding the spatial_ref_sys to the public schema, is there anything I should be aware of?