Best practice for multiple data contexts for accessing different databases with different schemas

[BenjaBobs]

I'm in a situation where I have to work with multiple SQL databases, each with their own schemas and domains.
What I would like to do is write type safe methods for doing domain specific business logic for each, such that I cannot use a business logic on a connection that fits the wrong domain.

Example:

public static class FruitConnectionExtensions
{
  public static async Task EatFruits(this IDataContext fruitConnection)
  {
    // Do some fruit specific stuff
  }
}

public static class AnimalConnectionExtensions
{
  public static async Task Bark(this IDataContext, int dogId)
  {
    // Log that the dog barked
  }
}

The issue comes when both of these come into play in the same assembly, and I end up creating footguns for myself:

var fruitConnection = FruitFactory.GetConnection();
var animalConnection = AnimalFactory.GetConnection();

await fruitConnection.EatFruit(); // OK
await animalConnection.Bark(2); // OK

// Error because the relevant tables don't exist in the database
// And besides this business logic doesn't make sense
await fruitConnection.Bark(2);

I was hoping to get some compile time verification that I'm dealing with the correct connection, but I can't see that there's a generic IDataContext.
If there were, I would have all my fruits implement a IFruitTable marker interface, so I could do generic type restrictions on my extension methods, like this:

public static class FruitConnectionExtensions
{
  public static async Task EatFruits<TFruitTable>(this IDataContext<TFruitTable> fruitConnection)
    where TFruitTable : IFruitTable
  {
    // Do some fruit specific stuff
  }
}

But the lack of a generic interface also makes me think maybe I'm barking up the wrong tree here, and what I want to do is not idiomatic.
What is the best practice for handling this kind of situation?

[viceroypenguin]

Presumably you already have a class FruitDbContext : DataConnection and a class AnimalDbContext : DataConnection (which would also give you access to the tables on those connections); so you could just write the extensions:

public static class FruitConnectionExtensions
{
  public static async Task EatFruits(this FruitDbContext fruitConnection)
  {
    // Do some fruit specific stuff
  }
}

public static class AnimalConnectionExtensions
{
  public static async Task Bark(this AnimalDbContext animalContext, int dogId)
  {
    // Log that the dog barked
  }
}

[BenjaBobs]

I did in fact not, I had a simple DataConnection, and just exposed the IDataContext.
Subclassing does make sense though, it gives me everything I need!
Thanks! for the advice and quick reply!

[viceroypenguin]

Sure. Keep in mind that you can construct your DbContext classes to have the necessary tables on the class directly (which is how most people use l2db). It would look something like this:

public class FruitDbContext : DataConnection
{
  public ITable<Apple> Apples => this.GetTable<Apple>();
  public ITable<Banana> Bananas => this.GetTable<Bananas>();
}

This would help you construct queries directly from the context reference.