thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Reynolds <>
Subject Re: Can separate generated serialization code from generated datatype definitions?
Date Mon, 22 Dec 2014 05:33:47 GMT
Thanks for the advice about Hibernate.

On Fri, Dec 5, 2014 at 2:03 PM, Matt Chambers <> wrote:
> Unless something has changed recently, Hibernate is not a serialization framework, its
just an ORM.

Strictly speaking, unless your database is in the same process,
serialization is a requirement of every ORM.
I don't know of ANY way to get an object out of running process (into
a file, a database, or another process) without serialization. I'm not
being pedantic here -- it seems like a strict general requirement. We
can split semantic hairs, but Hibernate, Jackson, and many other
frameworks use annotations for getting business objects in out out a
Java process.

>        @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;
>        }

... entails a lot of error-prone busywork that would be better automated.

My point is, its a common necessity to serialize/unserialize objects
during communication with MANY different processes, each ultimately
serialized over various protocols --- we deal with with: cassandra,
REST, JSON RPC, Thrift RPC, sql, redis ...., all variously dealing
with the serialization of business objects. I'd rather not have to
visit 5 pieces of code when adding, removing or renaming an object
field. Part of the great benefit of thrift (beyond formalizing an IPC
procotol) is eliminating exactly this kind of manual and error-prone
data marshaling. However, this is (unnecessarily) at the expense of
removing automated data-marshaling benefits for each of the other many
external processes a develop might deal with. It unnecessary because a
cleaner design can separate automated serialization code from
developer controllable class definitions.

Anyhows.... it looks like thrift2swift was exactly the answer I was
looking for, and is working pretty intrusively:
Generates IDLs from class definitions under my control and plays
nicely with other system ==> huge win for code simplicity and

- Stuart

View raw message