Auto configure class persistence by convention

jshellman · **Joined:** Thu Jun 02, 2005 9:36 am **Posts:** 20

Has anyone worked on some code that would automatically configure the mapping by convention from a JavaBean?

So, I write my JavaBean:

public class MyBean() {...}

And without any mapping configuration whatsoever (have to do hibernate config so it can know what datasource to talk to, but that's it), I can just say:

session.save(myBean);

and it will automatically introspect myBean, configure the Configuration, sessionFactory (whatever necessary) appropriately, and persist myBean.

Anyone? I'm thinking this could make using hibernate for simple projects extremely easy since you wouldn't need all the overhead of configuring the persistence for each bean. So I've been thinking I might do it. But if anyone has already did it--I didn't want to reinvent the wheel.

Thanks!

jesse_sweetland · **Posted:** Mon Aug 15, 2005 9:26 pm

This might be of interest:

http://hibernate.org/200.html

Quote:

Representation Independance (done)

Hibernate was conceived as a persistence solution for POJO domain models, and that remains the focus. Occasionally, we run into people who would like to represent their persistent entities in some more dynamic way - as a map, essentially. Hibernate3 lets you represent your domain model as trees of maps, or, with a little bit of user-written code, as just about anything.

<dynamic-class> mappings, to allow a persistent HashMap
support for "named" entities, so different instances of the same class may be persisted to several tables
user-extension framework in the property and proxy package
In particular, Hibernate now supports the mapping of dom4j XML trees directly to the relational database.

query XML directly using HQL or the Criteria query API
make XML data persistent via the Session API
replicate data between systems using XML as an intermediate format, together with the replicate() operation

You will have a lot of problems generically saving POJO instances in the traditional sense, even if you require strict naming conventions. However, if you can serialize an object tree in XML and use this new facility to save and load it as a tree of HashMaps, then that would be a real quick and dirty persistence solution (even more so if it created its own tables on the fly).

- Jesse

jshellman · **Joined:** Thu Jun 02, 2005 9:36 am **Posts:** 20

Thanks for the reply.

The problem I'm suggesting is actually quite straightforward. I'm just looking at the small set of problems for which typically people would likely think Hibernate is overkill. So far as I can tell, there is no reason for Hibernate not to handle these simple applications just as well as it handles the complex ones.

Anyway... I'll assume noone has done it for hibernate. There are other projects doing it in their own frameworks--but so far as I know they don't scale up like hibernate does, so I thought it would be more useful to focus on hibernate scaling down so I can get the best of both worlds from a single product.

emmanuel · **Posted:** Mon Aug 15, 2005 9:44 pm

I don't believe in the late binding stuff, but look at Hibernate Annotations and the configuration by exception model + .par archive, it fits your simplicity needs I guess. You basically needs to have 2 annotations to make a class persitable

anar · **Posted:** Mon Aug 15, 2005 11:23 pm

I did some entity beans with hibernate recently using only two annotations...
@entity and @id. The rest was auto-discovered based on class and property names. I don't think it can be less than that.

Code:

import java.util.Collection;
import javax.ejb.*;
import javax.persistence.*;

@Entity
public class User implements java.io.Serializable, Cloneable
{
    public static final long serialVersionUID = 11111;
    private int id;
    private String username;
    private String password;
    private String name;
    private String email;
 
   /**
     * @return Returns the id.
     */
    @Id(generate=GeneratorType.AUTO)
    public int getId()
    {
        return id;
    }
    /**
     * @param id The id to set.
     */
    public void setId(int id)
    {
        this.id = id;
    }
    /**
     * @return Returns the password.
     */
    public String getPassword()
    {
        return password;
    }
    /**
     * @param password The password to set.
     */
    public void setPassword(String password)
    {
        this.password = password;
    }
    /**
     * @return Returns the username.
     */
    public String getUsername()
    {
        return username;
    }
    /**
     * @param username The username to set.
     */
    public void setUsername(String username)
    {
        this.username = username;
    }
  
    /**
     * @return Returns the email.
     */
    public String getEmail()
    {
        return email;
    }
    /**
     * @param email The email to set.
     */
    public void setEmail(String email)
    {
        this.email = email;
    }
    /**
     * @return Returns the name.
     */
    public String getName()
    {
        return name;
    }
    /**
     * @param name The name to set.
     */
    public void setName(String name)
    {
        this.name = name;
    }
}

I think perhaps hibernate with annotations is a good simplification to use.

jshellman · **Joined:** Thu Jun 02, 2005 9:36 am **Posts:** 20

This is a very good example of what I'm talking about. Aren't those two annotations obviously quite sane defaults? So why require them at all?

Anyway, I know there are probably mixed feelings about that by various people. But it seems to me that it would be quite useful to support very quick development or prototyping, to have your example work with no annotations at all--the metadata would be figured out automatically.

I'm not suggesting this should go on the roadmap, as it has been indicated this may not be in line with the primary goals of Hibernate. However, I consider it useful for certain things and if no one else has done it, I might.

emmanuel · **Posted:** Tue Aug 16, 2005 7:55 am

You might remove the need of @Id if you expect the entity to have a "getId", but you will not be able to remove the @Entity need.
Because before save, loading, querying you need to know all the entities. Think about relationships, inheritance etc etc. There are no sensitive values for those ones.

anar · **Posted:** Tue Aug 16, 2005 5:48 pm

I am not sure...

without @entity notation, how do you know whether on not to generate metadata for a class or not?...not all classes in the app will be mapped to db.