Is it possible to Extend the model class ?

[inawlaljar]

Please suggest whether it is possible to extend the model class.

i.e. for humour

@TableModelSpec(className = "Organization", tableName = "organizations") public class OrganizationSpec { }

[sbosley]

Sorry, I'm not sure if I understand what you're asking. The code you posted will generate:

public class Organization extends TableModel {
    ...
}

Do you then want to create a subclass of Organization? What specifically are you hoping to accomplish? You can of course subclass the generated model classes but needing to do so is an uncommon use case -- there may be a better approach depending on what you're actually trying to do.

[inawlaljar]

Thanks. While reading the data (json formatted) from the server using retrofit, I am converting the json into objects for which I have simple POJOs which are quite similar to Models required for Squidb. As you can imagine then I have to convert them in to Squidb models to persist them in the local db. Now, any change I bring in I have to modify both the classes. I was thinking of deriving one from another ... that will reduce the potential errors

For e.g. public class OrganizationResponse extends Organizations { } OR

public class OrganizationSpec extends OrganizationResponse { }

[sbosley]

I see. There are several considerations here:

The first thing to note is that squidb model specs are not really meant to be used as POJOs -- they're just defined that way as a shorthand for a table schema. They're processed by the code generator and translated into entirely different objects, and these generated classes are the ones you actually work with when reading/writing the database. No matter what, you will need to define some kind of logic for mapping your JSON to the generated squidb models in order to persist them.

That being said, there are options, and you can pick whatever approach seems best to you:

1. Define some logic to map the JSON directly into your squidb models, bypassing the intermediate POJO representation. This could perhaps even be automated with some kind of code generation plugin, although that would take some extra work to make it work with all possible JSON -> squidb model mappings.
2. Make your POJO object for the JSON extend from the model spec class. This doesn't help with the mapping problem, but at least it guarantees if you modify the model spec, the same field will be added to the JSON POJO, if that's what you want.
3. Make your model spec extend from the POJO object. This might be the most difficult of the options, and also will not solve the mapping problem; again it would only guarantee that any field added to one class will be included with the other. This option is more difficult because squidb only process the fields in the model spec class by default (not fields in any of its superclasses), so you would need to write a code generator plugin to handle this as well.
4. Make your POJO class and your model spec class one and the same. This is kind of a weird option, as I imagine fields in your JSON may not correspond directly to database columns in all cases. You'd have to keep in mind that in squidb model specs, field <--> column, and potentially annotate fields that didn't correspond to columns with @Ignore, and do something similar for any database columns that didn't correspond to a JSON field. Again though, you would still need to define logic for mapping your POJO to the generated squidb model.

Personally I would probably go with option 1 much of the time, but I don't know all the details of your use case and you may very well have different needs (e.g., maybe you're using an API that already defines those POJOs and precludes that option).

For information on code generation plugins, see this wiki page.

If you have more questions or want to provide any more specific details, happy to continue helping or offering advice! I hope that gives you some useful things to think about though.

[sbosley]

I'm going to close this issue as there hasn't been any activity on it in a while, but feel free to reopen if you have any more specific questions.