What do you think of this relational/object mapping approach
You must be logged in to the O'Reilly Network to post a talkback.

Showing messages 1 through 12 of 12.

• Middlegen
  2005-12-13 08:18:59  landro [Reply | View]
  
  
  Have you had a look at Middlegen - http://boss.bekk.no/boss/middlegen/
  
  Middlegen also generates O/R mappings based on the database.
• Middlegen
  2005-12-14 00:00:34  Norbert.Ehreke [Reply | View]
  
  
  Thanks. I'll check it out!

• Generic Type Information and Reflection
  2005-12-11 12:25:37  toga98 [Reply | View]
  
  
  As the previous poster mentioned, you could add generics to the BeanReader interface. More importantly your statement that generics and reflection don't mix is incorrect or at least misleading. The generated classes still contain the generic type information and it is accessible at runtime via reflection. See java.lang.reflect for more information.
• Generic Type Information and Reflection
  2005-12-14 04:18:11  BrunoVernay [Reply | View]
  
  
  There are some info about "Generic reflections" here :
  http://www-128.ibm.com/developerworks/java/library/j-cwt11085.html#h2
  
  Looks like your code readability will suffer if you use it. But I won't bite you whatever you decide.
  
  I admire your calm, given the disrespectful responses you get for having made your work freely available and an article about it. Some criticism are more devastating than contructiv. No matter why so many switch to RoR and its friendly community.
• Generic Type Information and Reflection
  2006-01-01 21:54:46  Norbert.Ehreke [Reply | View]
  
  
  Bruno, this is a cool link! It would have been really helpful if I had known about it and not rely so much on the Tiger: A Developer's Notebook. I'll think about dropping the authors of this one a note on that topic. But there is a valuable lesson learned from this: It's always good to check what other people claim, even if they are the super experts. Thanks a lot for the hint and also for your kind remarks.

• I always wondered...
  2005-12-09 03:11:23  mjmeijer [Reply | View]
  
  
  Put into a provocative statement: the middle tier is implemented as a set of stored procedures.
  
  Indeed, all textbook references promoting the three tier architecture were only just covering up for the fact that the databases we used (mysql, etc.) were simply not sophisticated enough.
  
  All business logic ultimately belongs in the database, where it can be accessed with a simple presentation layer only application.

• Generics and Roundtrips
  2005-12-08 22:01:09  Norbert.Ehreke [Reply | View]
  
  
  Sean,
  
  thank you for your candid thoughts. Let me clarify some of the issues you have raised.
  
  It's important to understand Java Generics are a compiletime feature. This
  

  
  
  List<Foo> list1 = ArrayList<Foo>();
  
  List<Bar> list2 = ArrayList<Bar>();
  
  

  
  becomes that
  

  
  
  List list1 = ArrayList();
  
  List list2 = ArrayList();
  
  

  
  after compilation. The purpose of a BeanReader is to construct an object of an arbitrary class at runtime via reflection. The code BeanReader<T> can give me no information about class T at runtime, because T does not exist then. Assuming that your code might work I'll still need the specific argument T.class when instantiating the BeanReader. So, when I wrote that
  

  
  
  ArrayList<T> list = reader.executeCreateBeanList( "..." );
  
  

  
  will have the compiler issue a warning, I am right. Please
  check "Tiger: A Developers Notebook" on page 29.
  
  Still, you've raised a philosophical question: Suppose your
  code works, I'd agree that it is explicit, but is it more concise? Considering type erasure and the fact that I need T.class to dynamically construct the required object (say, of type Jedi) would it be better to have a generified class BeanReader<Class<T>> to get rid of the unchecked type warning even though this information cannot be accessed for reflection? It might be nice to read, but seems cumbersome to code, wouldn't you say?
  
  Then there is the issue you raised about roundtripping. You are
  right: In the example you brought up, the code I showed would
  perform poorly. What I did not show is that Amber supports you,
  if you wanted to join the Jedis and the Fighters on the database return a result set that contains Jedis (redundantly in their respective columns) and their Fighters (individually). You'd then create a class that holds a Jedi plus one single Fighter, load a list of this class (1 database query) and wrap it in mapper code where you'd extract the Jedis with their Fighter list. Roughly, wrapper class might look like this.
  

  
  
  class JediFighter {
  
    private Jedi _jedi;
  
    pirvate Fighter _fighter;
  
    public JediFighter() {
  
       _jedi = new Jedi();
  
       _fighter = new Fighter();
  
    }
  
    // annotated Jedi accessors map to _jedi
  
    // annotated Fighter accessors map to _fighter
  
  }
  
  

  
  The mapper code (in the client) would take a number of JediFighters and give you back a list of Jedis with their Fighters. It's not automatic and it requires an additional loop in the client, but when you need to minimize database calls, it does work with no roundtrips.
  
  However it seems to me that we agree that table joins should be done in the database. The same goes for filtering. This begs the question, why would you want to load 10000 Jedis into the client? If the user will filter them, this should be done in the database, right?
  
  I hope I shed some light on the issues you raised. Thanks again
  for contributing your thoughts.
• Generics and Roundtrips
  2005-12-12 10:11:37  SeanReilly [Reply | View]
  
  
  
So, when I wrote that

ArrayList<T> list = reader.executeCreateBeanList( "..." );

will have the compiler issue a warning, I am right.

  
  Ahem. While technically true that you are able to understand why the compiler has an issue with your code, that doesn't change the fact that you weren't correctly dealing with the issue.
  
  From your article:
  
  
The compiler will issue a warning here, since the reader only knows at runtime what kind of class it is going to create. Because of type erasure in the generics implementation of J2SE 5.0, it is not possible to safely cast the result. And, sadly, it is also not possible to write the BeanReader class as BeanReader<Jedi> for the same reason. In short, using Java reflection and generics don't mix.

  
  The original article claims that this kind of operation is "not possible". I provided you with a code example that proves that it is, if you use the correct syntax. You then replied that you were correct in describing the original compiler warning. This doesn't have much to do with the very relevant fact that the framework and example use the wrong syntax.
  
  
you've raised a philosophical question: Suppose your code works, I'd agree that it is explicit, but is it more concise? Considering type erasure and the fact that I need T.class to dynamically construct the required object (say, of type Jedi) would it be better to have a generified class BeanReader<Class<T>> to get rid of the unchecked type warning even though this information cannot be accessed for reflection? It might be nice to read, but seems cumbersome to code, wouldn't you say?

  
  Your philosophical objections to the correct syntax are between you and the people at Sun responsible for Java language syntax. Until such time as the offical language spec changes to accomodate your preference, choosing convenient syntax over over correct syntax is a bug. That is precisely why the compiler warns you about it.
  
  
You are
right: In the example you brought up, the code I showed would
perform poorly. What I did not show is that Amber supports you,
if you wanted to join the Jedis and the Fighters on the database return a result set that contains Jedis (redundantly in their respective columns) and their Fighters (individually). You'd then create a class that holds a Jedi plus one single Fighter, load a list of this class (1 database query) and wrap it in mapper code where you'd extract the Jedis with their Fighter list.

  
  Ah, I see. By "supports you", you really mean "allows you to do all of the work yourself". The primary requirement of an O/R framework is to convert relations into object hierarchies (hence the name). A framework that doesn't do this is basically useless. All this code provides is the simple ability to use reflection to unmarshall a simple result set into a simple object (or list of objects), but not a hierarchy. In other words, this is something that one could eventually use to build an O/R framework, but it isn't one itself.
  
  
This begs the question, why would you want to load 10000 Jedis into the client? If the user will filter them, this should be done in the database, right?

  
  10000 was used as an example to illustrate the ridiculous absurdity of the example's performance. The code is still bad even if it returns only a half dozen results, but it is less obvious to the untrained eye.
• Generics and Roundtrips
  2006-01-01 19:18:27  ridder [Reply | View]
  
  
  Shame on you Sean, for being such a jerk! It must be hard to be as smart as you. How do you put up with simpletons like the rest of us? It's too bad you can't find a nice way to educate the rest of us. Perhaps you can write a O/R mapper and an article and then we tell you about all your mistakes!
  
  As far as I'm concerned, this once again shows the lameness of generics in Java.
• Generics and Roundtrips
  2005-12-13 23:26:51  Norbert.Ehreke [Reply | View]
  
  
  I am glad that you pointed out how to improve the code. I'll definitely consider generifying the relevant classes, as long as the tradeoff between strict syntax and readability are balanced. The danger that the code poses are not as grave as you apparently perceive it. We all had to deal with Java lists and subsequent unsafe typecasts for the longest time. If an unchecked warning is a bug to you then I'd be curious to see, how you introduce Java Generics into a large codebase from code < J2SE5.
  
  As for the usefulness of Amber you and I differ in our expectations. To me a framework is useful if it lets me do the things I want to do with comparable ease. Your claim that the code example invalidates the approach in general doesn't make sense to me -- I showed how roundtripping can be avoided, if that is a concern. That this is not provided by the framework as an automatic feature has also been discussed in the article. The important aspect is that you can construct your object model based on what the database returns. The fact that Amber does not dictate an object model but lets you decide how to do it is a feature -- well, at least to us. Finally, code that is easy to use and to maintain is often more valuable than highly optimized code. You will clearly not use the library, fine, but I can assure you that it works very well for us. Our customers have not complained about performance at all. Oh, and, you might have noticed that I never claimed that Amber is an O/R framework. There is a conceptual difference, hence the title.
  

• More on the things the author of this article got horribly wrong
  2005-12-08 09:00:54  SeanReilly [Reply | View]
  
  
  (aka: Welcome to programming)
  
  In my previous post, I commented on the author's skill and experience with java generics (or horrible lack thereof). This time, the subject is databases, and how the techniques mentioned in this article are an excellent example of how not to access them correctly.
  
  From the original:
  
Et voila, there you have all of the Jedi with a collection of their respective fighters. Note that we have not coded the reading of the Fighter collection into the Jedi class. This would mean tight coupling between the Jedi and the Fighter.

  
  Wow. Sir, if any of your databases are on fire, may I humbly suggest the above code as a possible culprit.
  
  With the exception of a few highly specific cases which are well beyond the scope of an article like this, a relational database process and a java application server are never in the same process. In fact they are commonly not even on the same physical server. This means that the round trip from the app server to the database has cost, often measureable in milliseconds or more.
  
  Consider a case where there are 10000 jedi, each with 0 or more ships. Querying this information in a join would incur the cost of 1 roundtrip. The method described above would incur the cost of 10001 round trips. If you've ever heard some of your more knowledgable colleagues mention the n + 1 loading problem, this is what they were talking about.
  
  In addition to the phenomenal overhead incurred in app server/database traffic, this approach is also more expensive at a pure database level. The join can be processed as two ordered table scans, plus a nested loops join operation. In constrast, the n + 1 loading approach will incur 1 table scan, plus 10000 index seeks.
  
  For someone whose stated goal is minimizing poor database behavior, this is coming up a bit short.
  
  As the author of this article is also the author of the library in question, my concerns about the quality of the Amber framework are grave indeed. It's too bad really, because I agree that slaving the object behavior to the relational behavior is a promising approach to minimizing o/r impedence.
  
  In the mean time, where's BileBoy when you need him?

• Generics and reflection don't mix?
  2005-12-08 08:36:34  SeanReilly [Reply | View]
  
  
  From the article:
  

  
  
  The compiler will issue a warning here, since the reader only knows at runtime what kind of class it is going to create. Because of type erasure in the generics implementation of J2SE 5.0, it is not possible to safely cast the result. And, sadly, it is also not possible to write the BeanReader class as BeanReader<Jedi> for the same reason. In short, using Java reflection and generics don't mix.
  
  

  
  
  Shame on you! This is not an example of reflection and generics not mixing. Instead, it's an example of the author not programming generics properly, which would be forgiveable, except that he is writing an article about generics. Sir, your knowledge of the subject matter at hand is so poor that I'm upset with the editor (if there even was one) that let this article through!
  
  For the record, the correct way to write this kind of thing is:
  

  
  
  BeanReader<Class<Jedi>> reader = new BeanReader<Class<Jedi>>(Jedi.class, connector);
  
  
  
  Collection<Jedi> jediList = reader.executeCreateBeanList("blah");
  
  

  
  
  This compiles perfectly properly without any compiler warnings.