Generic CRUD DAO about jdbi HOT 4 CLOSED

Perhaps you can use this project which builds on JDBI and adds CRUD and Dao capabilities: https://gitlab.com/mvysny/jdbi-orm

from jdbi.

Right, there is no one obvious right way to do this. To get something flexible enough for general purpose use, you need to get into the realm of O/R Mapping etc. I think once you go down that path, you are probably better off using a tool which really wants to do O/R Mapping (Hibernate, OpenJPA, etc).

I think there is certainly room for some basic mapping functionality, but I would be very careful about including it in the core.

I'd probably start with chained statement locators and a base dao interface which is type parameterized on the dto type. Then make a child interface which makes the DTO type concrete (so that classmate can figure out the type). You can then guess table names and field names from the dto type, or use jpa or jdo annotations to override behavior. How fancy you get is up to you.

This is the path, btw, of just using JDBI as a sql execution layer for an ORM -- if you cannot use the most basic things, and you want sophisticated ORM, then use HIbernate or OpenJPA.

from jdbi.

I strongly believe that there is no need a deep O/R mapping. Almost all projects would be mapped by simple functions. All necessary things is registering a strategy. A translating strategy is a two separated function which will provide same values. f(dbName) = g(propertyName) = z

public interface TranslatingStrategyAware {
    public TranslatingStrategy getDbTranslatingStrategy();
    public TranslatingStrategy getPropertyTranslatingStrategy();
}

And a strategy must not be changed from one db to another

 dbi = new DBI(datasource);
 dbi.setTranslatingStrategy(someStrategy)

Default strategy is lowering for both db and property as in BeanMapper you have done. BTW I have dropped my requests for snake case because of this. My pull requests are not addressing real problem entirely. A bean mapper with a strategy is not the solution for snake case problem. Database should has a strategy not mapper.

But I am not sure how StatementLocator, StatementRewriter and other parts will get this information. This might break backward compatibility by introducing some new parameters to StatementRewriter, StatementLocator etc.

And could you please explain this part? Especially first part.

I'd probably start with chained statement locators and a base dao interface which is type parameterized on the dto type.

from jdbi.

So setting this globally feels off, it seems like a function of the bean mapper.

Perhaps an argument to BeanMapper() ?

I think folks usually use BeanMapper via map(Class), which makes it a tad awkward, but I'd be happy to consider overloading that method to accept a name translator of some sort, as you suggest.

from jdbi.