Community
Participate
Working Groups
I have a "simple" result set that returns a row consisting of 60+ columns. Now, when doing a non object query an Object array will be returned and a I have to know where each value is located in that array. A Map<String,Object> would add much more convenience as I would just have to reference the value by its sql column name.
Created attachment 194704 [details] Added support for a Map being transferrable by CDO
The idea is not bad. Some questions though: 1) Why do you call the new CDOType HASHMAP and not MAP? 2) Your I/O code implies String keys. Why aren't they handled more generally (like the values)? In case you want to keep the String keys, how could we rename the CDOType to make that clear? 3) Can you write a couple of test cases to protect us against regressions? Thank you, Erdal ;-)
And please confirm that: 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines.
1) I thought it should be HASHMAP as internally java.util.HashMap is used to create the MAP and there are other implementations available. Maybe, it is good to make the user aware of this by calling it "HASHMAP". 2) The jdbc column labels/names of a result set's meta data are always Strings. Maybe, we can call the type HASHMAP_OF_STRING_TO_OBJECT or if HASHMAP is not ok call it MAP_OF_STRING_TO_OBJECT? 3) I can provide some test cases in SQLQueryTest like testNonCDOObjectQueries_Complex and replace the indexes by String keys :-) (In reply to comment #2) > The idea is not bad. Some questions though: > > 1) Why do you call the new CDOType HASHMAP and not MAP? > 2) Your I/O code implies String keys. Why aren't they handled more generally > (like the values)? In case you want to keep the String keys, how could we rename > the CDOType to make that clear? > 3) Can you write a couple of test cases to protect us against regressions? > > Thank you, Erdal ;-)
(In reply to comment #3) > And please confirm that: > > 1) The number of lines that you changed is smaller than 250. I confirm. > 2) You are the only author of these changed lines. I am. > 3) You apply the EPL to these changed lines. I do. (Sounds like a proposal of marriage :-)
Created attachment 194815 [details] Test case to handle sql result as map
Created attachment 195340 [details] This replaces CDOID.NULL by java null value when MAP is read by I/O on client side
Your test code reveals an issue with Map<String, Object>. To make the Java compiler happy one had to write: @SuppressWarnings("unchecked") List<Map<String, Object>> results = (List<Map<String, Object>>)(List<?>)query.getResult(Map.class); I already see myself explaing that to users again and again. A horror :P I've fixed that in bug 345456 so that we can now write: List<Map<String, Object>> results = query.getResult();
Regarding the name of the CDOType, how do you like "Record"?
Forget my RECORD naming proposal. I've rewritten your new CDOType so that it can work with arbitrary key types. Now it makes sense to call it MAP (HASHMAP would make it harder to exchange the impl class later).
Created attachment 195391 [details] Patch v3 (includes test)
Committed revision 7678 (sorry this contains some changes that would belong to bug 345456)
Thank you, Erdal ;-)
Available in R20110608-1407
