Tutorial 01

A simple table mapping

  <table name="MEMBER">
    <column name="MEMBER_ID" required="true" primaryKey="true" type="INTEGER"/>
    <column name="LOGIN_NAME" required="true" size="99" type="VARCHAR"/>
    <column name="PASSWORD_VALUE" size="99" type="VARCHAR"/>
    <column name="NAME" required="true" size="255" type="VARCHAR"/>
    <column name="EMAIL" size="255" type="VARCHAR"/>
    <column name="CONFIRM_VALUE" size="99" type="VARCHAR"/>
        <unique-column name="LOGIN_NAME"/>

This is probably easy to understand.
The xml is almost identical as the one used in Torque project, a damn nice project. It is like the Torque one because: 1-If it already exists, why should we create another format? 2-It was supposed to be compatible with Torque XML schema, maybe one day it will.
After running Gerbo, it will process the XML file, and generated some classes. Member.java is a important one. You will be able to:

      Member member = new Member();
      member.setLoginName(new String("name"));
      member.setPasswordValue(new String("password"));
      member.setName(new String("full name"));
      member.setEmail(new String("email"));
      member.setConfirmValue(new String("other value"));

For testing this, refeer to howto-gerborun.
Yes, it is simples like this, now you have a row inside your Member table on the database, with the values given in the java code.
Now, you can get the data back:
	Collection c;
	Iterator i;
	c = MemberBroker.selectAll();
	i = c.iterator();

	while (i.hasNext()) {
		Member member = (Member) i.next();

And you will get:

(name=full name)(email=email)(confirmValue=other value)}

If you want, you can easily delete all rows:
	Collection c;
	Iterator i;
	c = MemberBroker.selectAll();
	i = c.iterator();

	while (i.hasNext()) {
		Member member = (Member) i.next();
		System.out.println("Deleting row number:" + member.getMemberId());

Gerbo always maps a SQL columns to a java class, never a primitive.
Ok, that is enough for now. Lets see what kinda of variables Gerbo can map.


The folowing types are supported for now
sql typejava

* Maybe it would be nice if the text was represented by a StringBuffer, since it can get pretty big, and you do searchs and replaces inside a text field pretty offen.
** It is a String right now, because java.util.Date is so DAMN deprecated. We are looking for GregorianCalendar, maybe. (There is no getGregorianCalendar() in the ResultSet class, damn)
Check the project homepage, to se the TODO list, opver there you can look in what we are working, I mean, what are the new features, column types and databases that we are trying to support.