Missing import table model in generated models

[MFlisar]

I have a package structure like following:

• db
  • group1
  • Model1EntrySpec
  • group2
  • Model2EntrySpec
  • viewmodels
  • MyViewModelSpec

If I now do something like following in Model1EntrySpec

@ModelMethod
public static void function(Model1 item, Model2 model2) {
    // ...
}

I see, that the generated Model1 class is missing the import ....db.group2.Model2... The same happens in similar use cases, when using Model1 or Model2 in the MyView class...

I'm using the latest version 3.1.2...

[sbosley]

Yeah, this is a known annoyance of using annotation processing for code generation. When referring to classes that don't exist yet, the APT tool chain represents them as an ErrorType, which has no package information, so it's impossible to generate an import statement from an unqualified class name. This isn't much of a problem for things needed only at runtime -- for example, it's safe to refer to the properties of classes that haven't yet been generated when constructing the query for a view -- but it's a problem when the classes are needed at compile time, like in the method signature of your example model spec.

A workaround is to declare the method using the fully qualified class name of the generated class:

@ModelMethod
public static void function(Model1 item, com.yourpackage.db.group2.Model2 model2) {
    // ...
}

[MFlisar]

Isn't it possible to use the imports from the the model spec class? Anways, I could have thought about using fully qualified class names myself. This solves the problem of course

[sbosley]

To answer your question about using the imports from the model spec class: sadly it is not really possible. The annotation processing API doesn't give you access to the import statements themselves in the source file, and for some reason it doesn't use those imports to resolve any information about those ErrorTypes it provides. So even if you have import com.yourpackage.db.group2.Model2, if Model2 doesn't exist yet it still only represents the Model2 param in the method as an ErrorType with name Model2, no package info.

The only way to get them would be to somehow figure out where the source file is located and manually parse it for import statements, which, while probably technically possible, is an ugly hack that I'm not super eager to integrate into SquiDB as an officially supported thing. Might be possible to hack together with a code generation plugin though, so if this becomes a major burden that people are dealing with it we might revisit solutions then.

[MFlisar]

It would be possible to annotate own imports, wouldn't it? It's not that important though, but makes the class look a little bit better...

But the fully qualified name is working as well and it's not a big problem, if you know it

[sbosley]

Sure, you could easily define a code generation plugin to look for something like an @Import(classNames={...} annotation and then add those imports to the generated class using the addRequiredImports() plugin method.