@Select(“SELECT * FROM users WHERE id = ?{1}”)
User selectUserById(int id);

@Select(“SELECT * FROM users WHERE age = ?{1}”)
List selectUsersByAge(int age);

You have many other options as well, including DataSets which are Lists that lazy-load their content.

I agree with that goal. Let in Spring / XML and you’re back at hibernate right? ;) And I’m happy not having to debug proxy problems

I have been trying to avoid direct dependency with Spring. Although, probably everybody use it with my framework, Kauklahti does not depend on any particular Spring version (which is nice).

You have to tell somehow anyway, what is the column name for each field (if not the same). I don’t know if handling this in Spring level would be any better than just coding it to Kauklahti Column. The goal of the framework is to avoid xml/annotation configuration and just code the solution.

But could you provide an example of how this would be handled in Spring level? I could perhaps see, the possible advantage of this approach.

Many-to-many mapping is not that intuitive right now. I will think about if it is possible to implement this in a simpler way. However, I would like to stick to one class per table strategy anyway.

Currently I am coding a nice feature, that writes create table -statements based on Table-objects. With AutoConfigured JavaBean and HSQLDB, it is a kind of object database :) The real use is for unit testing. In development we may generate in-memory database and use it. In test environment we would use the same Table-mappings for a remote Oracle database.

I hope you don’t mind the aggressive feedback at TSS. That’s typical human reaction against anything new.

I have not tried Kauklahti – yet. However, I consider most ORM solutions for Java a major pain in the.. head; and if Kauklahti promises simplicity, that warrants that I give it a try.

Final hint is that if I were you I’d try to find some wants/needs that major ORMs such as Hibernate or iBatis do not fulfill (Plain simplicity is just great for a start).

Keep up the spirit and the good work :)

Even with the convention over the configuration, one has to write (2 lines) codes. Why not just create a spring bean and handle it in at the spring level? No codes is better than two :)

Thanks for quick update. Now to see how this may play a role within Seam framework.

I wasn’t aware guitars were so popular up there ;-)

Henry

I don’t know if you’ve heard of apache click but they too are people who are sick of the nightmare of overly complex frameworks… but your two projects fit like a glove!