Data Access Manager

Question

Hi all
I had to design a data access layer framework (yes, I DID suggest Hibernate at the time, duffy ;-)) and came up with a rather good solution, IMHO. As the data access should be generated by a tool, there's but one possibility : map one DTO per table and populate them in the DAO. That's how it was before I arrived and it won't change.
Here is how it works :
public interface DAO {
    // marker interface
// DAO interface for table 'xxx'
public interface XxxDAO extends DAO {
    public static final class Row {
        // column mappings to private java fields
        // full constructor
        // public getters & setters
    public Row get(/* primary key */);
    public Set<Row> select(/* index */);
    public int insert(Row row); // returns the serial if any
    public void update(/* primary key */, Row row);
    public void delete(Row row);
}It is sufficient to explain my problem :
1. there's no primary key in our tables (eeeeeeeeewwwww, I know, nobody listens to me)
2. OTOH there may be multiple unique indices
3. ... and of course many multiple non unique indices
instead of creating getX(), getY(), ..., selectX(), selectY(), blablabla... methods with as many parameters as the respective index holds, I'd like to be able to do something like :
    public Row get(Key key); // any existing unique index
    public Set<Row> select(Index index); // any existing non unique index
    public int insert(Row row); // returns the serial if any
    public void update(Key key, Row row); // here 'key' would be the "main" unique index (I'll deal with that ;))
    public void delete(Row row);But as soon as I start to think about how to modify the SQL implementation, I'm quite stuck. How could the (SQL)DAO know which key it receives and then build the query in an appropriate way ? I can't give any SQL responsibility to the Key class since it's intended to remain technology-independent, and a factory sounds heavy and dodgy to me...
Will I have to duplicate these get and select methods and give them unpronouncable names based on their index (indices can hold the same data types in the same order, unfortunately, that's why the Key/Index classes would have helped) ?
Do I have to design generic Key and Index classes that can be used as DTO for any query constraints (like an array containing the index fields as Objects)... by doing so, I stop enforcing that XxxDAO should only receive XxxKey and XxxIndex...
This problem is driving me mad, any help is welcome

Answer 1

I'd like to open by saying whoever suggested you
reduplicate the work of so many teams of people
single handedly is a complete and total idiot and you
should be sure you get paid for every minute of your
wasted time and futile effort.I sure will... ;-)
>
You need to generate SQL for everything. YOU are not
the one that gets to act like the database is
abstract, YOU are the one that gets to make it so
others can act that way..right
>
The key can most certainly have SQL. What you are
creating is your internal DAO, not what the end user
will think of as his DAO. He does not get to see
your key or what it really does. that's not how I was seeing things actually. I wanted to create the Key and Index class in order to facilitate the coder's life :
* unique index => Row get(Key) method
* non unique index => Set<Row> select(Index) method
As I want to "abstract myself away" from SQL (the data might come from a Web Service, flat files, or even Hibernate or any other O/R mapping tool), my (top) key (interface/class) shouldn't hold any implementation-specific code
so like with JDO
you can create your key based on the metadata of the
end user. that is how you know the type of key and
whatnot.
Why don't you tell that bonehead company to just
assign you to hibernate or jpox and allow you to work
there solving the same problem and getting much
faster results for us all, than this...
Facisinating.actually, at the time when the decision was made, Hibernate was (slightly) incompatible with older versions of the DBMS that's installed at our customers'
I bet it's not the case anymore now and we've spent money for nothing, but I'm not the one who gets to make the decisions ;-)