I hope this is not a pure example of blatant advertising, but it does seem related with the topic. We've managed to roll something which is really fat-free, uses only JDBC and SQL, and works with only one abstraction, which is grounded in mathematics.
https://github.com/novarto-oss/sane-dbc (The abstraction is the DB monad) It also deals with the mentioned falacy of make-believe you are working in the local process space, since the possibility of failure is baked into the DB<A> type. I think the design is minimal, and in some sense maximal in that you cannot achieve much more in Java without resorting to madness. I guess that makes it optimal in a certain sense. I do use it in production; hopefully somebody finds it useful. Regards, Dimitar On Monday, 25 August 2014 23:37:46 UTC+3, Kevin Burton wrote: > > Long thread... but I was thinking that another way to look at this is that > ORMs are generally mechanically unsympathetic. Because they're designed to > be sympathetic to the developer.. not the hardware. > > It would be nice if Java made it easier to make hardware sympathetic code, > AKA packed object, etc. > > But right now that's not the case. > > I recently wrote a simple ORM for spinn3r based on code generation using > VTL templates. For the most part I'm happy with it but the ORM part is so > thin that it's going to be very hard for it to get in the way. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
