Allow abstraction of MAPPER to work with Generics

If you have a number of tables that need to have Cursors mapped to Objects created by SqlDelight, then you will end up with duplicate code in many classes. In my code base, I have 6 tables that use 7 Loaders to retrieve data.

In the code below, this is the whole class from one of my Loaders, and the code in the loadInBackground() method is highly repetitive and could be moved to the superclass; however, in the current version of SqlDelight this doesn’t seem possible.

public class WorkLoader extends ProviderLoader<Resume.Work> {
//                                             -----------

    public WorkLoader(Context context) { super(context); }

    @Override
    public List<Resume.Work> loadInBackground() {

        List<Resume.Work> results = new ArrayList<>(5);
        Cursor cursor = getProvider().queryAllWork();
//                                    ^^^^^^^^^^^^^^
        while (cursor.moveToNext()) {

            results.add(Resume.Work.MAPPER.map(cursor));
//                      ^^^^^^^^^^^^^^^^^^
        }

        return results;

    }
}

In the above code, WorkLoader would not contain an overridden loadInBackground() method, but would implement an abstract method that would return a Cursor to the superclass and the super class would be able to determine the correct MAPPER in its loadInBackground() method.

Is something like this possible to implement?

[JakeWharton]

We have a RowMapper<T> interface all mappers implement for this.

You could use it like:

public abstract class ProviderLoader<T> extends Loader(?) {
  private final RowMapper<T> mapper;

  public ProviderLoader(Context context, RowMapper<T> mapper) {
    this.mapper = mapper;
  }

  @Override public final List<T> loadInBackground() {
    List<T> results = new ArrayList<>();
    Cursor cursor = getProvider().queryAllWork();
    while (cursor.moveToNext()) {
      results.add(mapper.map(cursor));
    }
    return results;
  }
}

and then call it like:

super(context, Foo.MAPPER);

from subclasses.

[JakeWharton]

Yeah, that was going to be my next suggestion since it not only lets you mark each type, but also perhaps partially mark them in any other ways you see fit to constrain your application-layer code.

On Fri, Jun 3, 2016 at 11:43 AM Christopher Rucinski < [e-mail]> wrote:

Well, first thing I just called it SqlDelightMarkerInterface for lack of trying. It would not have to be called anything that links it to SQL Delight because developers can roll their own solutions.

Anyways, if it was implemented, then it really wouldn’t force users to have to switch their current implementations that I can see. With the Marker Interface, you don’t really have the subclassing issue that most people associate as bad behavior as you won’t be subclassing your model classes (is there even a reason why you would? Possibly for a VIEW?).

So, as a developer I can implement that Marker Interface if it fits my needs or not. I would not be forced in any way I believe.

With that all said, there is already an area where the developers have to hook up the SQL Delight generated components…

@AutoValue public abstract class HockeyPlayer implements HockeyPlayerModel { public static final Mapper<HockeyPlayer> MAPPER = new Mapper<>(AutoValue_HockeyPlayer::new);

public static final class Marshal extends HockeyPlayerMarshal<Marshal> { }

}

It appears that the same effect that I was originally looking for can be implemented by the developer as so…

@AutoValue public abstract class HockeyPlayer implements HockeyPlayerModel, MarkerInterface { … }

As for as I remember, this will not be overridden by the auto-generated code. So, then there wouldn’t really be a need for it to be implemented as stated in my previous post, I think.

— You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub https://github.com/square/sqldelight/issues/308#issuecomment-223614748, or mute the thread https://github.com/notifications/unsubscribe/AAEEEQYeQqeg4HdpSYTR-Kgwwdn0-GRPks5qIEuMgaJpZM4ItOKE .