AW: CamelCase, Object Population and Relational Selects
Thoralf Rickert [EMAIL PROTECTED] schrieb am 09.12.2005 09:48:04: I apologize for posting things that are in the docs, to be honest I am still struggling with the format of the Torque docs. They seem to be very decentralized so it take me a while to find what I'm looking for. Yes, I know. For me, the HowTos are helpful but it's not easy to find them, if you start at http://db.apache.org/torque. The changing navigation bar on the left is not very comprehensible. This is a known problem which came up when the Torque was divided in several subprojects. Maven does not support generating a common documentation of several subprojects very well, but I hope to find a workaround. Perfect except once catch, that I can't figure out how to get Torque to generate the schema with that property (defaultJavaNamingMethod) attached to the database tag. I really want to avoid manually updating the schema every time it's generated, especially in the development phase. Ah, you're generating the schema file. Sorry, I don't do that, so I cannot say, how to setup Torque to create this attribute in the schema. Maybe it's not possible, so it could be a bug or a new feature. You could use a small xslt transformation to automatically add javaNamingMethod=nochange to the database tag. Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: CamelCase, Object Population and Relational Selects
Question 1: Is there a way to maintain the CamelCase of the tables
inside of the torque classes? ex: If I have a table named
accountTypes I get classes such as AccounttypesBase, AccounttypesPeer
and Accounttypes.
Is it possible to get proper casing out of Torque like
AccountTypesBase?
See docs:
table name=accountTypes javaName=AccountType
...
/table
Question 2: We are considering integrating with Torque and the object
model it creates more tightly. Currently we don't use the generated
classes much at all besides querying the database then pulling the
information out of the objects and translating it into something more
usable from a java perspective.
Hmmm, perhaps Torque is not what you need. But I'm not sure if there is
a framework that puts your database tables in a usable java
perspective. Torque isn't able to understand the background of your
database design.
[...]
example:
say there is a OM class called Account that relates to Company in the
database. Is there a way to get an Account object with a List
of Company
instead of a List of Account each one containing a Company object.
I'm a little bit confused about that example. Has Account a foreign key
to Company...
Then there will never be more then one company for one account.
... or is there something like a link table between Account and Company
(f.e. AccountCompanyAssignment)?
Then make a select with the account in the AccountCompanyAssigment and
join the companies. You will get a list of AccountCompanyAssignments.
Extract the companies from that list in a wrapper method in
AccountCompanyAssignmentPeer and return the list of companies:
public static List getCompanies(Account account) throws Exception {
Criteria criteria = new Criteria();
criteria.add(ACCOUNT_ID, account.getID());
criteria.addGroupByColumn(COMPANY_ID);
List result = doSelectJoinCompany(criteria);
List companies = new ArrayList();
for (AccountCompanyAssigment assignment : result)
companies.add(assigment.getCompany());
return companies;
}
Question 3: I see that there is a way to join against related tables,
and also a way to join against all related tables except a
certain one.
Perhaps it's a gross oversight on my behalf but is there a
way to join
against ALL relationships?
Create your own method by copying a doSelectJoinAllExcept*() method and
add the excepted related table. It's not difficult. I think there was
something in the documentation about this.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: CamelCase, Object Population and Relational Selects
This is a big help, thanks.
I apologize for posting things that are in the docs, to be honest I am
still struggling with the format of the Torque docs. They seem to be
very decentralized so it take me a while to find what I'm looking for.
Thoralf Rickert wrote:
Question 1: Is there a way to maintain the CamelCase of the tables
inside of the torque classes? ex: If I have a table named
accountTypes I get classes such as AccounttypesBase, AccounttypesPeer
and Accounttypes.
Is it possible to get proper casing out of Torque like
AccountTypesBase?
See docs:
table name=accountTypes javaName=AccountType
...
/table
You put me on the right track for the CamelCase issue I was having. But instead
of:
table name=accountTypes javaName=AccountType.../table
This does more of what I need.
database name=myDatabase defaultJavaNamingMethod=javaname.../database
The difference comes in schema generation. The property torque.sameJavaName = true will insert the attributes javaName into all the table declarations when the schema is generated with a value that matches the table name.
However most of my table names are similar to javaVariableNaming and the property defaultJavaNamingMethod will capitalize the first letter and leave the rest of the name alone.
Perfect except once catch, that I can't figure out how to get Torque to
generate the schema with that property (defaultJavaNamingMethod) attached to
the database tag. I really want to avoid manually updating the schema every
time it's generated, especially in the development phase.
Question 2: We are considering integrating with Torque and the object
model it creates more tightly. Currently we don't use the generated
classes much at all besides querying the database then pulling the
information out of the objects and translating it into something more
usable from a java perspective.
Hmmm, perhaps Torque is not what you need. But I'm not sure if there is
a framework that puts your database tables in a usable java
perspective. Torque isn't able to understand the background of your
database design.
[...]
example:
say there is a OM class called Account that relates to Company in the
database. Is there a way to get an Account object with a List
of Company
instead of a List of Account each one containing a Company object.
I'm a little bit confused about that example. Has Account a foreign key
to Company...
Then there will never be more then one company for one account.
... or is there something like a link table between Account and Company
(f.e. AccountCompanyAssignment)?
Then make a select with the account in the AccountCompanyAssigment and
join the companies. You will get a list of AccountCompanyAssignments.
Extract the companies from that list in a wrapper method in
AccountCompanyAssignmentPeer and return the list of companies:
public static List getCompanies(Account account) throws Exception {
Criteria criteria = new Criteria();
criteria.add(ACCOUNT_ID, account.getID());
criteria.addGroupByColumn(COMPANY_ID);
List result = doSelectJoinCompany(criteria);
List companies = new ArrayList();
for (AccountCompanyAssigment assignment : result)
companies.add(assigment.getCompany());
return companies;
}
Let me clear up my example, even though I think you have answered my
question. A wrapper method.
Account{accountId[pk], accountName}
Company{companyId[pk], accountId[fk.account.accountId], companyName}
Account.accountId has a foreign key of Company.accountId
If I were to select joins in Torque I believe I would get something like
this.
List [ Account{ Company } ]
Is an array of Account objects with populated Company objects, instead
of what I was trying for...
Account { List[Company] }
Which would essentially be a single copy of the Account object with a
List of Company objects which have common accountId.
Question 3: I see that there is a way to join against related tables,
and also a way to join against all related tables except a
certain one.
Perhaps it's a gross oversight on my behalf but is there a
way to join
against ALL relationships?
Create your own method by copying a doSelectJoinAllExcept*() method and
add the excepted related table. It's not difficult. I think there was
something in the documentation about this.
I recall something in the documentation about creating a doSelectAll() method that selects all the rows in a table. I don't remember one talking about the joinAll method.
In any case, you're right it isn't that hard to create a method of my own to do
the task. I just didn't want to have redundant functionality of something that
the Torque project maintains and I was too blind to see.
