>>>I agree that the existence of both SQL and EJB-QL is regrettable, but it cannot be addressed differently as of today. But the situation might look less grim to you if you think of a possible future where a bunch of new query languages have been invented besides SQL and OQL, and where the good news is: you don't need to learn them, just keep programming in EJB-QL and the container will generate the code for you. >>> I completely agree with Cedric. EJB QL certainly deserves to be openly debated and improved as a result of criticism, but faulting it for lack of rigidly paralleling SQL, which fails to satisfy so many EIS requirements, is a bit closed-minded. If the goal of EJB QL were to replace SQL, and if all EIS were RDBMS for now and ever more, then it would be a worthy criticism. But as it is, the two serve goals and requirements as different as that of BMP and CMP. Some developers may need deep portability and abstract persistence across EIS's that cannot or do not conform to the assumptions made of RDBMS's, or these developers may not be able to live entirely in Java for a project's entire lifecycle, or they may need to link disparate enterprises based on incompatible EIS's without stovepiping them together at the EIS layer. Other developers don't need any of these things, and merely want a simple O/R layer that performs decently. The default persistence facility of Java enterprise apps may likely be connectors and connector-specific EJB QL interpreters behind CMP entities. If a developer wishes to take advantage of automatic query generation based upon pluggable EJB QL interpreters, in the form of connector-based CMP, then that developer can create a single entity instantly portable across SAP, Oracle, etc. Developers crafting apps with deep and diverse requirements can take advantage of this. Such developers should go right ahead and black box the database -- that's one of the major intents of CMP! Those developers who do not have such requirements and can afford more intimate concrete schema knowledge may merely desire straight JDBC -- but these latter developers should not limit the former developers by forcing their somewhat simpler requirements onto the entire lot. Perhaps the majority of internal deployments are RDBMS-specific and use no other EIS. If that's the case, then perhaps the argument to make isn't whether EJB QL is as useful to you as SQL, but whether BMP and/or session beans make more sense than CMP in your app. I strongly support Cedric's optimism that container-managed persistence will eventually equal and surpass performance gained through use of RBMS-specific approaches. But in the meantime, today (and thank goodness this technology isn't architected only for today's "majority" common usages), it is hard to make that argument. The discussion reminds me of the IIOP debates. Those comfortable in an all-Java world (most page-oriented web app developers) see interoperability as an annoyance. Those with broader requirements to marry CORBA and non-Java enterprises to their own enterprises see it as a new solution where non existed before. EJB QL is similar but the stakes are higher; it is a new feature serving unique goals for those who need to take advantage of it, not a replacement for something that will still quite successfully and simultaneously serve another set of goals. psn =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff EJB-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
