I don't know. I have gotten around the problem for now, those were just issues that I found in my project development.
But I would think that removing the table aliases would be the best place to start because it seems like the easiest for you (the developer). You probably only have to modify one class.
It is true that any time the PersistenceBroker executes SQL against a connection it always goes to one table?
I mean, it doesn't do any type of join correct? You can't map a single class to multiple tables unless you use extents, correct?
If this is the case, I would start with removing the aliases and re-running the unit tests.
Jakob Braeuchi wrote:
hi bobby,
these are actually reasonable arguments. in these cases the fields have to be defined readonly then.
i'm not sure whether it's better to drop all the aliases where possible or whether we should introduce a new kind of readonly fielddescriptor for your requirements ?
wdyt ?
jakob
Bobby Lawrence schrieb:
Not having an alias would allow you to use functions and string literals.
You could specify a string literal in the field-descriptor like this:
<field-descriptor name="myField" column="' 'a string literal' ">
This would give you the same value for every class instance, which might not seem that useful at first, but this is exactly what I needed in my project for a brief time. At the time, I was expecting values from the database where the field did not exist yet and I needed something to test.
You could also specify functions in the field-descriptor like this:
<field-descriptor name="wholeName" column="CONCAT(CONCAT(firstname, ' ', lastname) AS wholename">
If using an Oracle database, this would concatenate the first and last names to give you a whole name.
Another example on concatenation w/ Oracle without using the function:
<field-descriptor name="wholeName" column="firstname || ' ' || lastname AS wholename">
All of these should be possible if OJB didn't use table aliases in its generated SQL statements.
What IS the benefit of using an alias?
Jakob Braeuchi wrote:
hi bobby,
i still do not get the benefit of not using an alias. could you please post a sample ?
jakob
Bobby Lawrence schrieb:
Well - it seems that the alias is not needed.
If the class only goes to one table for its data, why does the table need an alias?
If an alias was not used, you could specify string literals for a column name.
Jakob Braeuchi wrote:
hi,
ojb should always use the alias in front of the column name. if it does not, it could probably not translate the attribute name into a column name.
btw: what exactly is the problem with the alias ??
jakob
Vesely, Max [IT] schrieb:
Bobby,
I was able to do it by listing field names in a ReportQuery object. It also won't append table alias in front of the column name in this case.
Max.
-----Original Message-----
From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent: Thursday, January 20, 2005 5:38 PM
To: ojb-user@db.apache.org
Subject: remove table alias in generated SQL?
Is there a way to tell OJB to not use the table alias in front of the column names when it generates SQL?
Currently, when you specifiy that a class comes from <tableA> and a field of that class comes from <fieldA>, OJB executes the following SQL:
SELECT A0.<fieldA> FROM <tableA> A0
If you can't map one class to multiple tables, I don't see why this is necessary.
Is there any way around this?
Instead of mapping a field to a specific column, I want to map it to a string literal so that it always has the same value for the class.
Ex. <field-descriptor column= 'some literal' AS myColumn">
-- Bobby
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- ---------------------------- Bobby Lawrence MIS Application Developer
Jefferson Lab (www.jlab.org)
Email: [EMAIL PROTECTED] Office: (757) 269-5818 Pager: (757) 584-5818 ----------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
