Hi Jeff, > yes, i use a pseudonym on the jpox forum: farble1670. my real name is on my > profile. > why is this "sad"?
It's only sad in the respect that I couldn't find your name in the forum when I originally looked and posted here, nothing more. > as for nothing about perf, > 1. http://www.jpox.org/servlet/forum/viewthread?thread=2435#13175 > i quote eric: "This is a known issue with low priority now" These were from "jain_maneesha". I had no idea he was your colleague did I ? ( I do now though :-)) Things did change some time back on this issue to allow for caching of PreparedStatements. The overall JIRA issue for that item is left open since every possible situation isn't fully checked yet. Revisit it. > 3. http://www.jpox.org/servlet/forum/viewthread?thread=2436#13144 No idea on that one. Many things have changed since these were raised. They probably predate our use of JIRA so unless your colleague raised a JIRA it wont be registered. If the problem still exists (please check this with beta-6 - since many things have changed), then please raise a JIRA. That way you have something monitorable and can come back to, rather than just saying there are problems and that no one has responded to a forum post raised some 6 months ago. > i did not comment on jpox vs. hibernate. i don't know about that. my > comment referred to the fact that jpox is unoptimized in several areas > that prevent it from being used in applications with truly high > scalability requirements. maybe roller doesn't fit into that category, i am > not sure. Well I read "really very attrocious". That is certainly stronger than it deserved IMHO and the part of your post I object to. There are actually several people using it in highly scalable situations, but it comes down to your definition of "highly scalable" and what particular data structures you have. Many queries/fetches are optimised and maybe you've just happened across some that we haven't been near ? The benchmark highlights the general performance for handling large numbers of objects, and in the context of Roller is of use (even though certain people representing "other O/R persistence solutions" don't think so :-) ). There are some areas that deserve optimisation certainly, and we've been open about that haven't we ? The way for you to move that forward is to define the *precise* situations that you require optimised queries and they get worked on (certainly now JDO2 is not far from release). >> 3. Yes, JPOX does have "Java Persistence 1.0" on the roadmap. > is it a superset at the functionality or api level? if it's the latter, > great. > if it's the former, there's not a lot of point in coding to the JDO2 API if > it will > have to be ported to JP 1.0 in the near future. Look at the "Java Persistence 1.0" spec. API methods are in general a 1-1 mapping to an equivalent in JDO2, except that there are more methods in JDO2, and more metadata tags in JDO2. The idea here is that people should design their DAO layer to handle such a change - hiding the persistence technology specific stuff in a layer -- View this message in context: http://www.nabble.com/roller-%2B-jdo-jpox-t996892c12275.html#a2666633 Sent from the Roller - Dev forum at Nabble.com.
