manikandan-k / jdbi-folder Goto Github PK

Hi, I have been using JDBI-Folder for some time and now encountered something new when tried to join table that that has one-to-many mapping to enumerations.

Tables

• products (id, ...)
• items (id, fk_product_id, ...)
• features (fk_product_id, feature) //feature is custom enum type in PostgreSql

`
class Product {
@PrimaryKey
long id;

@OneToMany("items")
List items; //Item is a class, similar to Product

@OneToMany("features")
List feature; //Feature is an enum
}

interface ProductDAO {
@SqlQuery("""
select
p.*,
i.id items$id, ...
f.feature features$feature
from products p
left outer join items i on (p.id = i.fk_product_id)
left outer join features f on (p.id = f.fk_product_id)
...
""")
FoldingList findProducts(...);
}
`
findProducts() worked ok before adding the features join there, but now it does not return them.

I did get it to work by switching Feature enum class, to this:

class FeatureHolder {
//feature field in fact is not the PK but this is required to get more than 1 Feature out
@PrimaryKey
public Feature feature
}

So wondering if it would be possible to get List of enums instead of List of enum-holding-classes?

In-general this library works great and saved me a bunch of code to write, Thanks. I did just run into an issue with the hydration of my domain objects by the CustomMapperFactory: I have ubiquitously annotated all of the fields in my domain objects with @ColumnName("stuff") annotations and was experiencing a case where 2 of my columns were failing to hydrate (always coming through as NULL). The 2 columns specifically are Booleans stored in the database as an integer value 1 or 0 SO as far as jDBI and the Folder are concerned they are just Integer values (I interpret them as Boolean elsewhere) BUT given their nature I named the fields a bit different than the natural camel-case naming would be. I spent a lot of time triple checking all of the various Strings to make sure I didn't have any typos / etc and finally, on a guess, renamed the columns to be their "typical" camel case conversion and that fixed the problem. Here's what the fields in question look like:

// Didn't work... always NULL.
@ColumnName("IS_REPEATABLE")
private Integer repeatable;
@ColumnName("IS_MANDATORY")
private Integer mandatory;

// Successfully pulled values from DB queries.
@ColumnName("IS_REPEATABLE")
private Integer isRepeatable;
@ColumnName("IS_MANDATORY")
private Integer isMandatory;

As listed, these fields were originally named "repeatable" and "mandatory". Changing them to "isRepeatable" and "isMandatory" and changing their getters' naming to match caused them to successfully hydrate SO my presumption is that the annotations are being ignored. All of my other columns are working correctly but they were all already named the camel case equivalent of their columns so the annotations were redundant. Thanks

PS. For some reason GitHub is flattening the annotations in my issue description. FYI They are correctly cased "ColumnName" (capital C and N) even if it doesn't appear as such in the text above.

This is perfect! I was looking like a solution like this for my project. JDBI was painful with nested types. My question is - is this running somewhere in production etc? Just want to get an idea around stability.

Are you planning on releasing an update to make jdbi-folder compatible with JDBI3?

I added the maven dependency to my project, but it doesn't seem to resolve QueryLocator.