Public access to caches and metadata in Dapper.Contrib

[Koloto]

It would be nice to get public access to helper methods like GetTableName, TypePropertiesCache, KeyPropertiesCache (and other *Cache) etc. Of course, I can copy-paste all these methods:) But it will be double work in development and also in runtime.
But IMHO if you just change the access modifiers to public, the code will smell bad. Maybe introduce some static class, i.e. MetadataHelper or TypeUtils?

[NickCraver]

We'll likely largely refactor these in v2, so I'm a bit against exposing things we'd almost immediately break.

But it'd be helpful to know what you need - can you explain some example use cases and what you're after? That may help a bit on how we refactor things.

[Koloto]

Well, our team uses MS SQL sequences to generate IDs. And we want to specify the name of the sequence by the attribute:

    [Table("Address")]
    public class Address
    {
        [Sequence("AddressSequence")] // this is the custom attribute
        public long Id { get; set; }

        // other props
    }

Also our IDs typically have type long, not int (related to #994). Therefore, we can't just replace ISqlAdapter. I know, AdapterDictionary is the private field, but we can modify it via reflection - this is ugly hack:). It would be good to have an ability to add/replace adapters in v2. So we wrote custom extension method InsertSequence which is 80% similar to standard Insert. But all *Cache fields in SqlMapperExtensions are private and we should duplicate them:(.

I think, pluggable adapters and generic Insert<T, TKey> method in v2 will help us in this case. However I suppose, an access to helper caches and methods can be useful in some other cases. And we can't wait for v2:(

[NickCraver]

Unfortunately, thing isn't something we can do. For example there are PRs right now that change these structures. While they're internal, that's fine. When they're public, we're handicapped on any changes as they'd then be breaking and we have to wait for another major release. Because of that, we need to keep them private so we can tweak and fix things as we re-engineer how they work (they do need to change).

[NickCraver]

Collapsing this into #722 - that's where we'll be redesigning how this works and allowing the flexibility asked for here in v3 - that the goal.