Subclassing DBRow Subclasses

Subclassing DBRow is a vital part of the DBvolution system.

Subclassing the subclasses is very helpful too.

If your database has multiple connections between 2 tables, subclassing the original subclass allows you to differentiate the connects and insert a little more semantic information.

public class Staff extends DBRow{

    @DBForeignKey(Staff.Manager.class) DBInteger fkManager = DBinteger();
    @DBForeignKey(Staff.TeamLeader.class) DBInteger fkTeamLeader = DBinteger();

    public static class Manager extends Staff{}
    public static class TeamLeader extends Staff{}
}

The above code allows DBV to differentiate between 2 the foreign keys to Staff. That means you avoid the situation where DBV attempts to connect both keys to the same row. That might be correct sometimes but it's certainly not the 90% case.

Note that the subclasses don't have to actually change anything, just changing the class allows it to work.

Subclassing is also useful when there are actual defined subtypes within your tables. A database I use regularly has a "type number" column on almost all the tables. Subclassing allows those types to be easily added to queries:

public class Staff extends DBRow{

    @DBColumn
    DBInteger typeNumber = new DBInteger();

    public static class Manager extends Staff{
        {typeNumber.permittedValue(1);}
    }
    public static class TeamLeader extends Staff{
        {typeNumber.permittedValue(2);}
    }
}

The class above has built-in support for limiting your queries to only managers or team leaders. Wherever the @DBForeignKey class is Staff.class you can use Staff or any of it's subclasses.

Note that it doesn't work the other way: once a Manager, always a Manager.