Support for custom field types on generated resolvers

[RodrigoQuesadaDev]

Hi, first let me tell you that I think this project is absolutely great and you guys rock. Also, I wanted to ask you if there is a possibility for adding custom type converters/mappers for unsupported field types. Like for example, I have the next column definition in one of my objects:

@StorIOSQLiteColumn(name = "myDate") DateTime myDate;

But when trying to compile it I get the next error:

"Unsupported type of field for StorIOSQLiteColumn annotation, if you need to serialize/deserialize field of that type -> please write your own resolver: Unsupported type: org.joda.time.DateTime..."

So that means I have to write custom code for converting those fields of unsupported type each time, right? (I mean, I can obviously reuse code, but at least I have to extend the default generated resolvers and parse those fields myself, each time)

[artem-zinnatullin]

Hello @RodrigoQuesadaDev! That's nice idea, we have to think about implementation, at the moment I got 2 variants:

1. Add interface for converter and allow to specify class, which makes conversion per field:

// Name can be changed
interface SQLiteColumnConverter<YourType, SQLiteCursorType> {
  @NonNull
  YourType mapFromSQLiteCursorType(@NonNull SQLiteCursorType value);

  @NonNull
  SQLiteCursorType mapToSQLiteCursorType(@NonNull YourType value);
}

Example implementation for JodaTime's DateTime:

class DateTimeToSQLiteCursorTypeConverter implements SQLiteColumnConverter<DateTime, Long> {
  @Override @NonNull
  DateTime mapFromSQLiteCursorType(@NonNull Long value) {
    return new DateTime(value);
  }

  @Override @NonNull
  Long mapToSQLiteCursorType(@NonNull DateTime value) {
    return value.getMillis();
  }
}

And usage:

@StorIOSQLiteType(table = "sometable")
class SomeType {

  @StorIOSQLiteColumn(name = "dateTime", converter =  DateTimeToSQLiteCursorTypeConverter.class)
  DateTime dateTime;
}

Ah, I have to go, I'll post second variant of implementation later!

[RodrigoQuesadaDev]

Awesome, I had also thought about implementing it similarly but I think you could also just add an annotation for the converters, like this:

@FieldConverter
class DateTimeToSQLiteCursorTypeConverter implements SQLiteColumnConverter<DateTime, Long> {
    ...
} 

So that you don't need to specify the converter as part of the @StorIOSQLiteColumn annotation (although you could leave it optional, to work as override?). But anyway, I'm not sure about it because I've never implemented a annotation processor (some day I will hehe). In any case thank you very much for taking your time to think about it.

[artem-zinnatullin]

I'm back, your variant is okay, but I guess that you may need to convert field of one type into different formats for different situations, for example you have Tweet and User and both of them has DateTime field which you would like to save as long for Tweet and as String for User, so you'll have two converters for one type (DateTime) — that's why first variant is to set converter per field (also, it'll give you MUCH more info when you'll open old or unknown project and you'll want to understand how fields get converted into DB format).

I didn't have a stable picture of the second variant in my head at the moment, we'll need to discuss this feature with @nikitin-da and then we'll add comment here, so stay tuned!

P.S.

Hi, first let me tell you that I think this project is absolutely great and you guys rock.

Thanks!

[mykola-dev]

any news on this issue? it is really blocker

[artem-zinnatullin]

@deviant-studio not yet, if it blocks you — you always can implement resolvers yourself, StorIO gives you such flexibility. This issue is hard to do correctly, I have some variants of implementation, but I guess it'll require some time.

Moving this to 1.7.0 release.

[mykola-dev]

ok. thanks

[artem-zinnatullin]

Another solution: store custom field as one of supported types and provide public getter/etc with custom type!

Example:

@StorIOSQLiteType(table = "some_table")
class SomeEntity {

  @StorIOSQLiteColumn(name = "registrationDate")
  long registrationDate;

   // Storing as long, but providing public access as DateTime!
  @NonNull
  public DateTime registrationDate() {
    return new DateTime(registrationDate); // if your entity is immutable, you can cache this value
  }
}

[artem-zinnatullin]

I'm moving this to v1.9.0, and finally I think I understand how to implement this correctly

[RickBoyerDev]

Hi, I'm new to StorIO and having trouble finding documentation. Can you point me to the documentation on this change as I want to implement a ColumnConverter for an enum.

Thanks for the library! There's a lot here to like, but it's slow getting started with it. (And I've set up MANY ORMs on Android.)

[geralt-encore]

@nightskydev Unfortunately, it hasn't been implemented yet.

[RickBoyerDev]

Thanks @geralt-encore ... just to be clear, this feature or the documentation has been implemented yet? (I thought this issue was part of v1.10.0?, or am I misunderstanding the milestone labels?)

[geralt-encore]

I am not in charge of milestones, so can't say anything about it. But I am sure that this feature hasn't been implemented yet (as well as documentation obviously).

[RickBoyerDev]

Ok, so the feature itself hasn't been implemented. I appreciate the response @geralt-encore!

[nikitin-da]

@nightskydev sorry for misleading with milestone
@geralt-encore is absolutely right, this feature hasn't implemented yet
There is separate issue on it, please follow #730

[RickBoyerDev]

Thanks @nikitin-da! I hope a "field converter" is implemented some day and not just support for enums.