EJB2.0 spec or implementation?
I've toyed with EJBs for quite a while, all the way back to 1.0. But so far its been too cumbersome and offered little gain in most environments I've been working in (e.g. the overhead of remote calls, etc, outweighed the potential benefits). Now with the 2.0 spec its gotten to a good place where I feel like it will really offer some improvements to almost any environment. But I have a major gripe about CMP that I'd like to hear if anyone can 'justify'. So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). In Java, case is available and useful, here common parlance is representing a space by a capital letter (e.g. 'thisField'). Unfortunately with the typical CMP EJB implementation of accessor-methods are a bastardization of both of these schools (e.g. 'getThis_field'), which is not only ugly but also makes it much more difficult to move from typical javabean-style Java into EJB. Since the 2.0 spec already requires abstract classes where the engine builds the concrete class, it seems like it would be a no brainer to map 'getThisField()' to the 'this_field' database field and preserve conventions on both sides of the fence. I'm sure people can come up with cases where this appears impractical, or a way to change some generated config file in orion after the EJBs have been deployed, but does anyone have any good ideas on why this is not the default behavior?
Re: [orion-interest]EJB2.0 spec or implementation?
On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
Re: [orion-interest]EJB2.0 spec or implementation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neither is Oracle. Oracle actually stores all its DB Fields upper case, but it doesn't matter how you refer to then, meaning select column1 from Table or select Column1 from table or select COLUMN1 FROM TABLE Doesn't make a difference. R At 01:25 PM 12/28/2001 -0500, you wrote: On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.3 for non-commercial use http://www.pgp.com iQA/AwUBPCzNZMCgz9HsAj5wEQI/awCfapbiZcITG3/twcV+IIpjlN3O15wAnAiJ yMf5L47Q9eFh9Y2ASuuwkIjT =Mwke -END PGP SIGNATURE-
RE: [orion-interest]EJB2.0 spec or implementation?
I'm fairly sure that the SQL-92 spec calls for case insensitive column names (but don't quote me on that cause I'm not 100% sure). Also, since I'm in a UNIX shop switching to Microsoft is not really an option (even *if* I wanted to) - but thats not really the point. More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. I was hoping that there was some way to do this without slicing up the post-deployment orion generated files. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 10:26 AM To: Orion-Interest [EMAIL PROTECTED]; Aaron Tavistock Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
RE: [orion-interest]EJB2.0 spec or implementation?
You think fugly? It already does fugly reflection and decapitalization for the first letter just to match the accessor to a column name. Why is it any more fugly to process underscores? I do suppose that databases that do identify case within the column name could make things a little wierd (e.g. would getThisField() translate to 'this_field' or 'thisField'?). But still I believe the SQL-92 spec is for case insensitive column names. From a perfromance standpoint, its practically no difference (all happens when the concrete class is created at deployment time). I'll try the orion-ejb-jar.xml, but I'm guessing I'm going to need to provide a complete orion-ejb-jar.xml file, not just the hierarchy required for the cmp-field-mapping fields. Theres a lot of junk in there I don't want to follow and if I'm doing quick development I will need to far more than makes sense. Which definately makes our existing persistence, caching, and coding paradigm easier to use than CMP EJB, once again seems to indicate that EJB might still not be needed for most serverside applications (still more hype and 'neat' technology than is practical in the majority of situations, IMHO). -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 12:32 PM To: Aaron Tavistock; Orion-Interest [EMAIL PROTECTED] Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 3:20 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. Well, this IS the correct way to do it. I don't see why you can't just do it once. Having a partial orion-ejb-jar.xml certainly does work. You just need to make sure it has sufficient information in it and is usable. Start off with a complete one and start trimming things, and check it works after every trim! Adding an automatic underscoring thing is too too fugly!
RE: [orion-interest]EJB2.0 spec or implementation?
Might I recommend xdoclet then? xdoclet.sourceforge.net At 12:20 PM 12/28/2001 -0800, Aaron Tavistock wrote: I'm fairly sure that the SQL-92 spec calls for case insensitive column names (but don't quote me on that cause I'm not 100% sure). Also, since I'm in a UNIX shop switching to Microsoft is not really an option (even *if* I wanted to) - but thats not really the point. More importantly, I'm aware I can change the post-deployment descriptor created by Orion but thats a major pain-in-da-behind if I'm doing development and want to redeploy several times. When I've tried putting an partial orion-ejb-jar.xml into the package, its never worked right, implying that I need to copy a previously deployed version to modify - again extremely cumbersome. I was hoping that there was some way to do this without slicing up the post-deployment orion generated files. -Original Message- From: Hani Suleiman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 28, 2001 10:26 AM To: Orion-Interest [EMAIL PROTECTED]; Aaron Tavistock Subject: Re: [orion-interest]EJB2.0 spec or implementation? On 28/12/01 12:56 pm, Aaron Tavistock [EMAIL PROTECTED] wrote: So heres the story - database field names are case insensitive, so common parlance for representing a space is an underscore (e.g. 'this_field'). Nope. MS SQLServer is not case insensitive. You could always tweak orion-ejb-jar.xml to map it to whatever column names your heart desires
