Question

I got a class:

 class Person{ 
   String name; 
   String surname; 
   String miasto; 
 }

And I would like to put object of this class into a single cell of database table. Is there any way to do this? How?

Answer 1

As a alternatives to using hstore as mu is too short explained, you have hstore, composite types, Java-serialized bytea, and xml.

• a composite type
• an XML document using the xml data type
• a JSON value using the json data type in Pg 9.2 beta and it’s 9.1-backported version
• hstore

I think hstore is probably a better choice, but this is a viable alternative and can be better for some uses. It’s hard to recommend one over the other since you haven’t explained what you’re trying to do and why.

An explanation of each of the options listed above follows.

Composite type

Composite types are structured and strongly typed, easy to query, quite expressive, fast, and preserve the full capabilities of the type system so you can have all sorts of complex values, arrays, etc in them. However, they’re a real pain to query and write in text form from application code, so you’ll often land up sending extra queries to work with them.

Don’t even think about using them from JPA and other ORMs like Hibernate – you’d think they’d support composite types with their @Embedded classes, but you’d be wrong.

It’s a truly painful experience to try to add to or alter a composite type once it’s in use. Keep that in mind.

CREATE TYPE person AS ( name text, surname text, miasto text );

CREATE TABLE some_table (id integer primary key, blah text, this_person person);

INSERT INTO some_table(id,blah,this_person)
VALUES (1,'fred',ROW('a','b','c'));

SELECT (this_person).name FROM some_table;

Access with:

regress=# SELECT * FROM some_table ;
 id | blah | this_person 
----+------+-------------
  1 | fred | (a,b,c)
(1 row)

or, to avoid having to parse composite-type row syntax:

regress=# SELECT t.id, t.blah, (t.this_person).* FROM some_table t;
 id | blah | name | surname | miasto 
----+------+------+---------+--------
  1 | fred | a    | b       | c
(1 row)

or as a separate SELECT:

regress=# SELECT (t.this_person).* FROM some_table t;
 name | surname | miasto 
------+---------+--------
 a    | b       | c
(1 row)

XML

The XML datatype implements the SQL/XML standard. It’s rich and portable. SQL/XML offers xpath support for querying XML values, you can write some quite complex and powerful queries on structured XML data. XML is easy-ish to work with in most applications, and in Java can be easily marshalled and unmarshalled from native Java objects using JAXB and the JAXB annotations.

You don’t need any extensions to Java or Pg to use XML.

XML values are structured, but the type isn’t, it accepts any well-formed free-form XML document or fragment. Add an IS DOCUMENT constraint to disallow fragments. Enforcing stricter structure is a pain. AFAIK Pg can’t currently validate XML against XML DSDs or other schema definitions in-database, so enforcing structure requires messy and slow xpath constraints.

XML values are not typed, values are stored as strings.

CREATE TABLE some_table (id integer primary key, blah text, this_person xml);

INSERT INTO some_table(id,blah,this_person)
VALUES (1,'fred', '<person><name>a</name><surname>b</surname><miasto>c</miasto></person>');

SELECT (xpath('/person/name/text()', this_person))[1] from some_table ;

JSON

JSON is a standard format that’s widely understood by many languages and applications. It’s fairly easy to work with. The JSON support in Pg is very new, and currently doesn’t have any functions or operators for manipulating and querying JSON, so it’s pretty opaque to the database right now; you can’t write queries like “find me json objects where the ‘name’ key begins with ‘a'”. Expect that to improve in 9.3.

JSON support doesn’t exist in the core Java SDK, but is available from several libraries, many of which support marshalling/unmarshalling to POJOs via JAXB binding extensions. See, eg Jackson’s JAXB support.

The JSON type accepts any well-formed JSON document. It doesn’t offer any way to enforce a particular structure. JSON values are typed, but only the limited set of types supported by JSON is accepted, everything else has to be stored as a string.

-- in Pg 9.2 and above; for 9.1 use the json91 backport
CREATE EXTENSION json;

CREATE TABLE some_table (id integer primary key, blah text, this_person json);

INSERT INTO some_table(id,blah,this_person)
VALUES (1,'fred', '{"name": "a", "surname":"b", "miasto":"c"}');

-- No easy way to subscript out json values in 9.1, but it's very convenient
-- with any app that has json support.

HSTORE

hstore is powerful and gives you lots of good predicates and operators to work with when querying the data. However, the format is non-standard and can be a pain to work with in application code. If using JDBC, org/postgresql/util/HStoreConverter.java and the PgJDBC hstore support will help a bit.

The hstore type accepts any hstore value. Structure may be enforced via CHECK constraints. hstore values are text; there are no data types in hstore.

-- In Pg 9.1 and above; for older versions hstore is available but is
-- added differently. See the documentation.
CREATE EXTENSION hstore;

CREATE TABLE some_table (id integer primary key, blah text, this_person hstore);

INSERT INTO some_table(id,blah,this_person)
VALUES (1,'fred', hstore(ARRAY['name','surname','miatso'], ARRAY['a','b','c']));

SELECT this_person -> 'name' from some_table ;

Serialization to binary in java

Probably the uliest option as the value is completely opaque to the database, but you can also serialize the value in Java and store it as bytea in the DB.

Whenever the class changes you have to write custom de-serialization routines to handle the old versions of the class still in the database. No non-java code can work with the value, and you can’t query it within the database.

—

It’d really help if you could explain what you’re trying to achieve with this and why.