Share the column and table name quote cache between connections

[casperisfine]

For apps using multiple database connections, especially if they are shards or replicas, different connections are very likely to share parts or all their table and column names.

Because of this I believe this cache should not be stored as an instance variable of ConnectionAdapter, but on the adapter class itself. This way all instances of a same type will share that same cache.

Should it use a Concurrent::Map ?

I believe it doesn't need it because if a race condition was to happen, both thread would generate the same value. So the locking needed would cause more harm than good.

cc @rafaelfranca @Edouard-chin @kaspth

[kamipo]

Is it intended to expose these in API doc?

[casperisfine]

Good point, no it's not. I think they should be private. Not sure what the best way to do it.

I can certainly # nodoc them, but they are still accessible. I'm open to suggestions.

[casperisfine]

I guess I could use class variables (@@) instead, but then I'm afraid about them being inherited, hence shared between distinct adapter implementations, in unexpected ways.

[diasjorge]

Maybe you could make it a protected class method?

[casperisfine]

Nope:

class Foo
  class << self
    protected

    def cache
    end
  end

  def access_cache
    self.class.cache
  end
end

Foo.new.access_cache # protected method `cache' called for Foo:Class (NoMethodError)

[ryantownsend]

@casperisfine I know this PR is a week old, but you said in your description:

different connections are very likely to share parts or all their table and column names

Doesn’t this change make the assumption that all connections will share these and effectively break scenarios where databases don’t match?

I might be missing something completely obvious, so thought I’d ask.

[casperisfine]

@ryantownsend I'm not quite sure to understand what you mean exactly.

The change make it so that the cache is now shared on the adapter class. Which mean it's only shared between connections of the exact same type. e.g. MySQL2Adapter won't share it's cache with PostgresAdapter.

Then, yes you'll only save memory if the two databases shared some column and table names. That's quite a common scenario if you make use of sharding, or simply use a read replica.

[ryantownsend]

@casperisfine ignore me – I've had some coffee and now understand this usage better. Apologies!

[krzcho]

What if I do not have exactly the same shards... I would prefer initial setup or being able to switch between the two.

[casperisfine]

What if I do not have exactly the same shards...

Then you don't gain much (I still bet your shards will share a few names such as id, updated_at, etc), but won't loose anything.

I would prefer initial setup

If by that you mean eagerloading of the cache, it's in my plans, but it's a little bit tricky.

[krzcho]

I guess I "gain" a cache that does not reflect database's state f.e. cache that the column exists while it actually isn't ; am I wrong here?

[casperisfine]

That cache doesn't "reflect" any state. It simply memoize table and column quotation:

"id" => "`id`"

There is no reason whatsoever for an application to reach directly into that cache.

So really, I don't understand why you are disturbed by it.

[krzcho]

yes, sorry, disregard; now I see which cache it is about; I was thinking about schema cache