You should just ditch Hibernate and if your using Spring just use JDBC template
and RowMapper.
Lets say you had a ProjectT struct like?:
struct ProjectT {
1:i32 id,
2:string name,
3:bool active
}
First, in your DAO class you want to accept a DataSource and create the
template.
private JdbcTemplate jdbc;
@Autowired
public void setDataSource(DataSource dataSource) {
this.jdbc = new JdbcTemplate(dataSource);
}
Then in your DAO, make a single static RowMapper which will convert a result
set into a single object, then you pass that into certain JDBC template
methods. (see below)
private static final RowMapper<ProjectT> MAPPER = new RowMapper<ProjectT>() {
@Override
public ProjectT mapRow(ResultSet rs, int rowNum)
throws SQLException {
ProjectT project = new ProjectT();
project.setId(rs.getInt("pk_project"));
project.setName(rs.getString("name"));
project.setActive(rs.getBoolean("active"));
return project;
}
};
Now you can add methods that your service will call into.
# SELECT * used for brevity in these examples.
# Get one of them.
public ProjectT get(int id) {
return jdbc.queryForObject("SELECT * FROM project WHERE pk_project=?",
MAPPER, id)
}
# Get all of them.
public List<ProjectT> getAll() {
return jdbc.query("SELECT * FROM project");
}
public List<String> getAllNames() {
return jdbc.queryForList("SELECT name FROM project", String.class);
}
You can use some Aspect Oriented techniques I posed about in the past to easily
convert Spring data exceptions to your thrift exception types as well. Once
you get setup with this is just a 1 liner to call into the DAO from your
service, then a 1 liner to do the query, and a single Aspect class that handles
exception conversion. You'll be surprised how fast you can whip out performant
services with this method, and its easy to bring in memcache or Google loading
caches as needed.
-Matt
On Dec 4, 2014, at 6:35 PM, Stuart Reynolds <[email protected]> wrote:
> I'm starting to use thrift for an existing Java/Scala project to
> provide RPC access to a set of services. One notable feature of Thrift
> (compared to other serialization frameworks) is that Thrift appears be
> responsible, not only for serialization, but also generating the
> (server) data structures. In many cases, this makes it difficult to
> use with existing methods of serialization, such as hibernate, that
> might employ annotation of types. :-(
>
> While there are workarounds - these are a LOT of work for an existing
> project and in some cases leads to additionally marshaling from
> Thrift's MyObject type to another same-but-different version of the
> same type -- its precisely this boilerplate that what I'd like to
> avoid by employing automated code generation.
>
> So, is it possible to separate the Thrift-generated serialization code
> from the POJO class definition (leaving my to edit those myself)?
>
> I suspect not because its looks like things are required to inherit
> from TBase, though I'm not sure how extensive this dependency is.
>
> (Am also looking at Swift, but am concerned about the overheards due
> to reflection).
>
> - Stuart
