Support polymorphic types

[Jeremy Kolb]

Does this library have any support for polymorphic types?

For example:

public interface INamedItem
{
    int Id { get; set; }
    string Name { get; set; }
}

public class Item1 : INamedItem
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class Item2 : INamedItem
{
    public int Id { get; set; }
    public string Name { get; set; }
}

public class ADataTable
{
    public int Id { get; set; }

    [OneToMany]
    public List<INamedItem> Items {get; set;}
}

[Jeremy Kolb]

I forgot the foreign key but you get the idea.

[Guillermo Gutiérrez]

The main problem with this approach is that library will be unable to build the items back to their original object. As it will be unable to distinguish between Item1 and Item2 as they will be the same object at database level.

Probably the write operations will work, but read operations will fail because it'll try to create an object of type INamedItem.

I can see that it would be useful in some cases, but it's not possible. For example, how the database schema would look if Item1 and Item2 would have additional properties? Usually in plain SQL you will create a table with the common columns and two more tables with the class specific columns. Another approach will be creating a 'fat' table containing all the columns for all the available subclasses. Neither of these approaches work with SQLite-Net, so there's no way that we could support them in SQLite-Net Extensions.

[Guillermo Gutiérrez]

This functionality won't be implemented anytime soon

[ShawnA]

I have a fork with this working. it requires a few changes around adding support for IoC containers to handle the resolution.

[Guillermo Gutiérrez]

@ravensorb I'm looking at your commit but due to indentation changes it seems that all the lines in both the write and read classes have changed. Can you point me out to the changes that you made?

[ShawnA]

I just pushed another commit that should take care of the entire implementation. Please note, that my changes depend on a pending pull request for the main SQL.Net.PCL library (also something that I did).

The main work is handed by two extension methods - GetResolver -- gets a resolver container from the SQLiteConnection object - ResolveType -- handles resolving the type if a resolver is defined and the type is an interface

Then if you look at all of the calls to "GetType" you'll see there is a call immediately after that to ResolveType. This handles resolving the types from interfaces to concrete objects if needed. We can probably clean this up more, but it gets the job done pretty well right now.

Here is a link to my fork of SQL.Net-PCL if you are curious.