ANY database?
Is the OJB compatible with ANY database? And is OJB compatible with Centura SQLBase? Thanks... __ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/
Mapping objects across multiple repositories
Hi, Is there any documentation regarding mapping objects across multiple repositories? Is it possible to map specific tables to a given respository, or is the connection used for the entire mapping. Thanks, Nuno Ochoa - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ANY database?
OJB uses different profiles for different databases, defaulting to a generic SQL profile is no more specific profile can be found. I suggest that you try out a simple test and see if it works, if so there is an extensive test suite that you could run to verify functionality. Also if your DB doesn't work fully, and you still want to use it and OJB then the customizations to make it work shouldn't be too painful. David Cavassana wrote: Is the OJB compatible with ANY database? And is OJB compatible with Centura SQLBase? Thanks... __ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/ -- Robert r. Sanders Chief Technologist iPOV (334) 821-5412 www.ipov.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoclet: generate interface descriptor
Maksimenko Alexander wrote: Sory for delay in answeing No my problem is that only class mapping wich has been proposed by Armin can solve my problem perfectly. But I cannt generate this class descriptor by xdoclet though its completely valid. Hi Thomas! would it be possible to change xdoclet to generate class descriptors wich want have table attribute and will have filed descriptoes please? or I should write mapping by hand in this case ? Thomas Dudziak wrote: The problem is that you need a table in order to map fields onto columns. Perhaps you could post your design ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VARCHAR columns?
Which API are you using? What does your criteria look like? Without knowing much about how you are selecting your data, I am going to guess that you are doing a 'addEqualToColumn' as opposed to 'addEqualTo'. The first one assumes the String you pass in is a column name (hence the lack of quotes around it), versus the value of a column. -Andrew -Original Message- From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 5:20 PM To: ojb-user@db.apache.org Subject: VARCHAR columns? I have a table called projects. Given a project_id (VARCHAR) in one table, I want to look up the project object from the projects table. The projects table has a primary key (project_id) that is also defined as a VARCHAR. Problem is, when OJB writes the select statement, it doesn't include the single quotes in the where clause. It creates the SQL like this: -- SELECT A0.PROJECT_ID, A0.LAST_NAME, A0.FIRST_NAME, A0.ORG_ID, A0.EMAIL_ADDRESS, A0.USER_NAME FROM PROJECTS A0 WHERE A0.PROJECT_ID = SDC010 -- Is this a bug? Am I doing something wrong? Repo.xml class-descriptor class=org.jlab.mis.services.mics.client.generated.ComputingJob table=jobs field-descriptor name=beginTime column=STIME jdbc-type=TIMESTAMP primarykey=true conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=endTime column=ETIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=queuedTime column=QUEUED_TIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=numNodesUsed column=NODE_COUNT jdbc-type=INTEGER/ field-descriptor name=numCpusUsed column=CPU_COUNT jdbc-type=INTEGER/ field-descriptor name=chargeFactor column=CHARGE_FACTOR jdbc-type=DOUBLE/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous/ reference-descriptor name=projectJobAllocatedAgainst class-ref=org.jlab.mis.services.mics.client.generated.Project foreignkey field-ref=projectId/ /reference-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / field-descriptor name=initialAllocation column=TOTAL_HOURS jdbc-type=BIGINT / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR / /class-descriptor Has anyone else experienced this? -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VARCHAR columns?
I am using the PersistenceBroker API and the error is happening in the retrieveReferences method. --B Clute, Andrew wrote: Which API are you using? What does your criteria look like? Without knowing much about how you are selecting your data, I am going to guess that you are doing a 'addEqualToColumn' as opposed to 'addEqualTo'. The first one assumes the String you pass in is a column name (hence the lack of quotes around it), versus the value of a column. -Andrew -Original Message- From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 5:20 PM To: ojb-user@db.apache.org Subject: VARCHAR columns? I have a table called projects. Given a project_id (VARCHAR) in one table, I want to look up the project object from the projects table. The projects table has a primary key (project_id) that is also defined as a VARCHAR. Problem is, when OJB writes the select statement, it doesn't include the single quotes in the where clause. It creates the SQL like this: -- SELECT A0.PROJECT_ID, A0.LAST_NAME, A0.FIRST_NAME, A0.ORG_ID, A0.EMAIL_ADDRESS, A0.USER_NAME FROM PROJECTS A0 WHERE A0.PROJECT_ID = SDC010 -- Is this a bug? Am I doing something wrong? Repo.xml class-descriptor class=org.jlab.mis.services.mics.client.generated.ComputingJob table=jobs field-descriptor name=beginTime column=STIME jdbc-type=TIMESTAMP primarykey=true conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=endTime column=ETIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=queuedTime column=QUEUED_TIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=numNodesUsed column=NODE_COUNT jdbc-type=INTEGER/ field-descriptor name=numCpusUsed column=CPU_COUNT jdbc-type=INTEGER/ field-descriptor name=chargeFactor column=CHARGE_FACTOR jdbc-type=DOUBLE/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous/ reference-descriptor name=projectJobAllocatedAgainst class-ref=org.jlab.mis.services.mics.client.generated.Project foreignkey field-ref=projectId/ /reference-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / field-descriptor name=initialAllocation column=TOTAL_HOURS jdbc-type=BIGINT / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR / /class-descriptor Has anyone else experienced this? -- 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] - 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]
composite foreign key references
Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? -- 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]
Re: VARCHAR columns?
Hi Bobby, I wrote a test case using VARCHAR as PK,FK columns similar to yours (auto-retrieve for the 1:1 reference is 'false'). This test pass with latest from CVS. Did you try latest version from CVS (OJB_1_0_RELEASE branch)? regards, Armin The test: String name = testAutoRetrieveFalse_ + System.currentTimeMillis(); Contract contract = new Contract(); contract.setPk(C+System.currentTimeMillis()); contract.setContractValue1(name + _Contract); contract.setContractValue2(1); contract.setContractValue3(contractvalue3); contract.setContractValue4(new Timestamp(System.currentTimeMillis())); RelatedToContract rc = new RelatedToContract(); rc.setPk(R_ + System.currentTimeMillis()); rc.setRelatedValue1(name + _RelatedToContract); contract.setRelatedToContract(rc); broker.beginTransaction(); // auto-update is true broker.store(contract); broker.commitTransaction(); broker.clearCache(); Identity oid = broker.serviceIdentity().buildIdentity(contract); Contract newC = (Contract) broker.getObjectByIdentity(oid); // auto-retireve is false assertNotNull(newC); assertNull(newC.getRelatedToContract()); broker.retrieveAllReferences(newC); assertNotNull(newC.getRelatedToContract()); Bobby Lawrence wrote: I am using the PersistenceBroker API and the error is happening in the retrieveReferences method. --B Clute, Andrew wrote: Which API are you using? What does your criteria look like? Without knowing much about how you are selecting your data, I am going to guess that you are doing a 'addEqualToColumn' as opposed to 'addEqualTo'. The first one assumes the String you pass in is a column name (hence the lack of quotes around it), versus the value of a column. -Andrew -Original Message- From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 5:20 PM To: ojb-user@db.apache.org Subject: VARCHAR columns? I have a table called projects. Given a project_id (VARCHAR) in one table, I want to look up the project object from the projects table. The projects table has a primary key (project_id) that is also defined as a VARCHAR. Problem is, when OJB writes the select statement, it doesn't include the single quotes in the where clause. It creates the SQL like this: -- SELECT A0.PROJECT_ID, A0.LAST_NAME, A0.FIRST_NAME, A0.ORG_ID, A0.EMAIL_ADDRESS, A0.USER_NAME FROM PROJECTS A0 WHERE A0.PROJECT_ID = SDC010 -- Is this a bug? Am I doing something wrong? Repo.xml class-descriptor class=org.jlab.mis.services.mics.client.generated.ComputingJob table=jobs field-descriptor name=beginTime column=STIME jdbc-type=TIMESTAMP primarykey=true conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=endTime column=ETIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=queuedTime column=QUEUED_TIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=numNodesUsed column=NODE_COUNT jdbc-type=INTEGER/ field-descriptor name=numCpusUsed column=CPU_COUNT jdbc-type=INTEGER/ field-descriptor name=chargeFactor column=CHARGE_FACTOR jdbc-type=DOUBLE/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous/ reference-descriptor name=projectJobAllocatedAgainst class-ref=org.jlab.mis.services.mics.client.generated.Project foreignkey field-ref=projectId/ /reference-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / field-descriptor name=initialAllocation column=TOTAL_HOURS jdbc-type=BIGINT / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR / /class-descriptor Has anyone else experienced this? -- 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] - 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]
Re: VARCHAR columns?
What database are you using? I am using text files and the StelsCSV JDBC driver for text files. This is the only database I have had this issue with --Bobby Armin Waibel wrote: Hi Bobby, I wrote a test case using VARCHAR as PK,FK columns similar to yours (auto-retrieve for the 1:1 reference is 'false'). This test pass with latest from CVS. Did you try latest version from CVS (OJB_1_0_RELEASE branch)? regards, Armin The test: String name = testAutoRetrieveFalse_ + System.currentTimeMillis(); Contract contract = new Contract(); contract.setPk(C+System.currentTimeMillis()); contract.setContractValue1(name + _Contract); contract.setContractValue2(1); contract.setContractValue3(contractvalue3); contract.setContractValue4(new Timestamp(System.currentTimeMillis())); RelatedToContract rc = new RelatedToContract(); rc.setPk(R_ + System.currentTimeMillis()); rc.setRelatedValue1(name + _RelatedToContract); contract.setRelatedToContract(rc); broker.beginTransaction(); // auto-update is true broker.store(contract); broker.commitTransaction(); broker.clearCache(); Identity oid = broker.serviceIdentity().buildIdentity(contract); Contract newC = (Contract) broker.getObjectByIdentity(oid); // auto-retireve is false assertNotNull(newC); assertNull(newC.getRelatedToContract()); broker.retrieveAllReferences(newC); assertNotNull(newC.getRelatedToContract()); Bobby Lawrence wrote: I am using the PersistenceBroker API and the error is happening in the retrieveReferences method. --B Clute, Andrew wrote: Which API are you using? What does your criteria look like? Without knowing much about how you are selecting your data, I am going to guess that you are doing a 'addEqualToColumn' as opposed to 'addEqualTo'. The first one assumes the String you pass in is a column name (hence the lack of quotes around it), versus the value of a column. -Andrew -Original Message- From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent: Thursday, March 10, 2005 5:20 PM To: ojb-user@db.apache.org Subject: VARCHAR columns? I have a table called projects. Given a project_id (VARCHAR) in one table, I want to look up the project object from the projects table. The projects table has a primary key (project_id) that is also defined as a VARCHAR. Problem is, when OJB writes the select statement, it doesn't include the single quotes in the where clause. It creates the SQL like this: -- SELECT A0.PROJECT_ID, A0.LAST_NAME, A0.FIRST_NAME, A0.ORG_ID, A0.EMAIL_ADDRESS, A0.USER_NAME FROM PROJECTS A0 WHERE A0.PROJECT_ID = SDC010 -- Is this a bug? Am I doing something wrong? Repo.xml class-descriptor class=org.jlab.mis.services.mics.client.generated.ComputingJob table=jobs field-descriptor name=beginTime column=STIME jdbc-type=TIMESTAMP primarykey=true conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=endTime column=ETIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=queuedTime column=QUEUED_TIME jdbc-type=TIMESTAMP conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times tampFieldConversion/ field-descriptor name=numNodesUsed column=NODE_COUNT jdbc-type=INTEGER/ field-descriptor name=numCpusUsed column=CPU_COUNT jdbc-type=INTEGER/ field-descriptor name=chargeFactor column=CHARGE_FACTOR jdbc-type=DOUBLE/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous/ reference-descriptor name=projectJobAllocatedAgainst class-ref=org.jlab.mis.services.mics.client.generated.Project foreignkey field-ref=projectId/ /reference-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / field-descriptor name=initialAllocation column=TOTAL_HOURS jdbc-type=BIGINT / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR / /class-descriptor Has anyone else experienced this? -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VARCHAR columns?
the generated SQL look like (with maxDB):
1110826600968|15|0|statement||SELECT pk FROM Contract WHERE pk =
'C1110826600515'
1110826600984|0|0|statement||SELECT pk FROM RelatedToContract WHERE pk =
'R_1110826600515'
1110826601000|16|0|statement||INSERT INTO RelatedToContract
(pk,relatedValue1,relatedValue2,relatedValue3) VALUES
('R_1110826600515','testAutoRetrieveFalse_1110826600515_RelatedToContract','0','')
1110826601031|31|0|statement||INSERT INTO Contract
(pk,contract_value1,contract_value2,contract_value3,contract_value4,fk_to_related)
VALUES
('C1110826600515','testAutoRetrieveFalse_1110826600515_Contract','1','contractvalue3','2005-03-14
19:56:40.515','R_1110826600515')
1110826601031|0|0|commit||
1110826601031|0|0|statement||SELECT
pk,contract_value1,contract_value2,contract_value3,contract_value4,fk_to_related
FROM Contract WHERE pk = 'C1110826600515'
!! this is correct
1110826601046|0|0|statement||SELECT
pk,relatedValue1,relatedValue2,relatedValue3 FROM RelatedToContract
WHERE pk = 'R_1110826600515'
Armin Waibel wrote:
Hi Bobby,
I wrote a test case using VARCHAR as PK,FK columns similar to yours
(auto-retrieve for the 1:1 reference is 'false'). This test pass with
latest from CVS.
Did you try latest version from CVS (OJB_1_0_RELEASE branch)?
regards,
Armin
The test:
String name = testAutoRetrieveFalse_ + System.currentTimeMillis();
Contract contract = new Contract();
contract.setPk(C+System.currentTimeMillis());
contract.setContractValue1(name + _Contract);
contract.setContractValue2(1);
contract.setContractValue3(contractvalue3);
contract.setContractValue4(new
Timestamp(System.currentTimeMillis()));
RelatedToContract rc = new RelatedToContract();
rc.setPk(R_ + System.currentTimeMillis());
rc.setRelatedValue1(name + _RelatedToContract);
contract.setRelatedToContract(rc);
broker.beginTransaction();
// auto-update is true
broker.store(contract);
broker.commitTransaction();
broker.clearCache();
Identity oid = broker.serviceIdentity().buildIdentity(contract);
Contract newC = (Contract) broker.getObjectByIdentity(oid);
// auto-retireve is false
assertNotNull(newC);
assertNull(newC.getRelatedToContract());
broker.retrieveAllReferences(newC);
assertNotNull(newC.getRelatedToContract());
Bobby Lawrence wrote:
I am using the PersistenceBroker API and the error is happening in the
retrieveReferences method.
--B
Clute, Andrew wrote:
Which API are you using? What does your criteria look like?
Without knowing much about how you are selecting your data, I am going
to guess that you are doing a 'addEqualToColumn' as opposed to
'addEqualTo'. The first one assumes the String you pass in is a column
name (hence the lack of quotes around it), versus the value of a column.
-Andrew
-Original Message-
From: Bobby Lawrence [mailto:[EMAIL PROTECTED] Sent: Thursday, March
10, 2005 5:20 PM
To: ojb-user@db.apache.org
Subject: VARCHAR columns?
I have a table called projects.
Given a project_id (VARCHAR) in one table, I want to look up the project
object from the projects table.
The projects table has a primary key (project_id) that is also defined
as a VARCHAR.
Problem is, when OJB writes the select statement, it doesn't include the
single quotes in the where clause.
It creates the SQL like this:
--
SELECT
A0.PROJECT_ID,
A0.LAST_NAME,
A0.FIRST_NAME,
A0.ORG_ID,
A0.EMAIL_ADDRESS,
A0.USER_NAME
FROM PROJECTS A0
WHERE A0.PROJECT_ID = SDC010
--
Is this a bug? Am I doing something wrong?
Repo.xml
class-descriptor
class=org.jlab.mis.services.mics.client.generated.ComputingJob
table=jobs
field-descriptor name=beginTime column=STIME
jdbc-type=TIMESTAMP primarykey=true
conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times
tampFieldConversion/
field-descriptor name=endTime column=ETIME
jdbc-type=TIMESTAMP
conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times
tampFieldConversion/
field-descriptor name=queuedTime column=QUEUED_TIME
jdbc-type=TIMESTAMP
conversion=org.apache.ojb.broker.accesslayer.conversions.Calendar2Times
tampFieldConversion/
field-descriptor name=numNodesUsed column=NODE_COUNT
jdbc-type=INTEGER/
field-descriptor name=numCpusUsed column=CPU_COUNT
jdbc-type=INTEGER/
field-descriptor name=chargeFactor column=CHARGE_FACTOR
jdbc-type=DOUBLE/
field-descriptor name=projectId column=PROJECT_ID
jdbc-type=VARCHAR access=anonymous/
reference-descriptor name=projectJobAllocatedAgainst
class-ref=org.jlab.mis.services.mics.client.generated.Project
foreignkey field-ref=projectId/
/reference-descriptor
/class-descriptor
class-descriptor
class=org.jlab.mis.services.mics.client.generated.Project
table=projects
field-descriptor name=id
Re: composite foreign key references
Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: composite foreign key references
Armin - I have to. I can a job table and a job class. The job table stores the project label. That is why it is listed as a primary key. I have to set it up this way. Can you help me with my problem? Armin Waibel wrote: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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]
Re: composite foreign key references
Bobby Lawrence wrote: Armin - I have to. I can a job table and a job class. The job table stores the project label. That is why it is listed as a primary key. I have to set it up this way. Can you help me with my problem? First, the PK declaration in OJB is independent from the PK declaration in your DB (but avoid constraint violations ;-)). OJB expects as FK fields in an object of a 1:n relation (PI) all PK fields of the main object (Project). In your case PI: fkFiscalYearId fkLabelId when Project has PK fiscalYear label collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=fkFiscalYearId / inverse-foreignkey field-ref=fkLabelId / /collection-descriptor HTH, Armin Armin Waibel wrote: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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]
Re: composite foreign key references
hi bobby, your problem could be solved by the new relationship-definitions based on non-pk-fields. this feature is available in the cvs trunk for ojb 1.1 Armin Waibel schrieb: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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]
Re: composite foreign key references
Armin- I can't use label as the key because to lookup a PI, I need the projectId and not the label. My problem is, OJB is using the value for projectId as the value for BOTH foreign keys (projectId and fiscalYear). Its not using the fiscalYear value in the query lookup. --Bobby Armin Waibel wrote: Bobby Lawrence wrote: Armin - I have to. I can a job table and a job class. The job table stores the project label. That is why it is listed as a primary key. I have to set it up this way. Can you help me with my problem? First, the PK declaration in OJB is independent from the PK declaration in your DB (but avoid constraint violations ;-)). OJB expects as FK fields in an object of a 1:n relation (PI) all PK fields of the main object (Project). In your case PI: fkFiscalYearId fkLabelId when Project has PK fiscalYear label collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=fkFiscalYearId / inverse-foreignkey field-ref=fkLabelId / /collection-descriptor HTH, Armin Armin Waibel wrote: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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]
Re: composite foreign key references
hi bobby, what version of ojb do you use ? jakob Bobby Lawrence schrieb: Armin- I can't use label as the key because to lookup a PI, I need the projectId and not the label. My problem is, OJB is using the value for projectId as the value for BOTH foreign keys (projectId and fiscalYear). Its not using the fiscalYear value in the query lookup. --Bobby Armin Waibel wrote: Bobby Lawrence wrote: Armin - I have to. I can a job table and a job class. The job table stores the project label. That is why it is listed as a primary key. I have to set it up this way. Can you help me with my problem? First, the PK declaration in OJB is independent from the PK declaration in your DB (but avoid constraint violations ;-)). OJB expects as FK fields in an object of a 1:n relation (PI) all PK fields of the main object (Project). In your case PI: fkFiscalYearId fkLabelId when Project has PK fiscalYear label collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=fkFiscalYearId / inverse-foreignkey field-ref=fkLabelId / /collection-descriptor HTH, Armin Armin Waibel wrote: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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]
Re: composite foreign key references
OJB 1.0.1 --B Jakob Braeuchi wrote: hi bobby, what version of ojb do you use ? jakob Bobby Lawrence schrieb: Armin- I can't use label as the key because to lookup a PI, I need the projectId and not the label. My problem is, OJB is using the value for projectId as the value for BOTH foreign keys (projectId and fiscalYear). Its not using the fiscalYear value in the query lookup. --Bobby Armin Waibel wrote: Bobby Lawrence wrote: Armin - I have to. I can a job table and a job class. The job table stores the project label. That is why it is listed as a primary key. I have to set it up this way. Can you help me with my problem? First, the PK declaration in OJB is independent from the PK declaration in your DB (but avoid constraint violations ;-)). OJB expects as FK fields in an object of a 1:n relation (PI) all PK fields of the main object (Project). In your case PI: fkFiscalYearId fkLabelId when Project has PK fiscalYear label collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=fkFiscalYearId / inverse-foreignkey field-ref=fkLabelId / /collection-descriptor HTH, Armin Armin Waibel wrote: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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]
Re: composite foreign key references
bobby, suppose your inverse-foreign key definitions in project point to the pk-fields of investigator, do you still have the problem that the same value is used for both attributes ? i do not ecpect so. ojb 1.0.x assumes that the inverse-foreign key points to the pk of the referenced class. a more flexible handling of inverse-fk will be available in 1.1 jakob Bobby Lawrence schrieb: OJB 1.0.1 --B Jakob Braeuchi wrote: hi bobby, what version of ojb do you use ? jakob Bobby Lawrence schrieb: Armin- I can't use label as the key because to lookup a PI, I need the projectId and not the label. My problem is, OJB is using the value for projectId as the value for BOTH foreign keys (projectId and fiscalYear). Its not using the fiscalYear value in the query lookup. --Bobby Armin Waibel wrote: Bobby Lawrence wrote: Armin - I have to. I can a job table and a job class. The job table stores the project label. That is why it is listed as a primary key. I have to set it up this way. Can you help me with my problem? First, the PK declaration in OJB is independent from the PK declaration in your DB (but avoid constraint violations ;-)). OJB expects as FK fields in an object of a 1:n relation (PI) all PK fields of the main object (Project). In your case PI: fkFiscalYearId fkLabelId when Project has PK fiscalYear label collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=fkFiscalYearId / inverse-foreignkey field-ref=fkLabelId / /collection-descriptor HTH, Armin Armin Waibel wrote: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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]
Problem with WSAD
Hello, I am currently using WebSphere Studio Application Developer (WSAD) v5.1.2 as my development environment. I created a WebSphere v5.1 Test Environment server within this and created a Data source with __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem with WSAD
Hello, I am currently using WebSphere Studio Application Developer (WSAD) v5.1.2 as my development environment. I created a WebSphere v5.1 Test Environment server within this and created a Data source with JNDI name jdbc/OJBTestDataSource using COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource as Implementation class for the Data source. Outside of this WSAD environment, I have my OJB test apparatus (repository*.xml files and java class files). In my repository_database.xml file, I have this setup: jdbc-connection-descriptor jcd-alias=OJBTest default-connection=true jdbc-level=2.0 jndi-datasource-name=jdbc/OJBTestDataSource batch-mode=false useAutoCommit=1 ignoreAutoCommitExceptions=false sequence-manager className=org.apache.ojb.broker.util.sequence.SequenceManagerHighLowImpl attribute attribute-name=grabSize attribute-value=1/ /sequence-manager /jdbc-connection-descriptor For my OJB test setup, I set the JAVA_HOME to C:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\runtimes\base_v51\java. I also added C:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\runtimes\base_v51\lib\namingclient.jar to my CLASSPATH and had to copy C:\Program Files\IBM\WebSphere Studio\Application Developer\v5.1.2\runtimes\base_v51\properties\implfactory.properties to my OJB test folder since it was complaining that this props file could not be found. Now, when I run my test client, I get the following exception: java.lang.ClassCastException: javax.naming.Reference at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.newConnectionFromDataSource(Unknown Sour ce) at org.apache.ojb.broker.accesslayer.ConnectionFactoryAbstractImpl.lookupConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionFactoryManagedImpl.lookupConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.ConnectionManagerImpl.getConnection(Unknown Source) at org.apache.ojb.broker.accesslayer.StatementManager.getPreparedStatement(Unknown Source) at org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsQueryObject.performQuery(Unknown Source) at org.apache.ojb.broker.accesslayer.RsIterator.init(Unknown Source) at org.apache.ojb.broker.core.RsIteratorFactoryImpl.createRsIterator(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getIteratorFromQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(Unknown Source) at PBTest.queryStuff(PBTest.java:80) at PBTest.runTest(PBTest.java:67) at PBTest.main(PBTest.java:166) This is apparently happening at ds = (DataSource) ic.lookup(jcd.getDatasourceName()); this line ConnectionFactoryAbstractImpl.java. I did a few sysouts, recompiled and found that the resultant object from the lookup is a javax.naming.Reference object and hence the cast to DataSource is failing. This works when I am using WebSphere v4.0 Test Environment. What changed from v4.0 to v5.1 in WebSphere? Or do I change something in OJB settings. Another big (or silly) question I have is, how does OJB figure out that it is looking up a resource deployed on WebSphere? Any help is greatly appreciated. Thanks, -Vamsi __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ojbdoclet and empty result files again
Hi users, I want to evaluate OJB for my project and have setup successfully (I think so) a maven task. All classes could be found and everything seems to run fine, but the result files (repository_user.xml) are empty... Anything I miss here? (See the post below are my maven goal definitions and console output) I searched the mailing list before posting here and found a posting very close to my problem, but that was not solving mine. :-( [snip maven.xml] goal name=provide-ojb-meta description=Parse ojb meta data and generate ojb files taskdef name=ojbdoclet classname=xdoclet.modules.ojb.OjbDocletTask classpath path refid=maven.dependency.classpath / /classpath /taskdef ojbdoclet destdir=ojb fileset dir=main/src/java includes=**/ojb/* / ojbrepository verbose=true / /ojbdoclet /goal [/snip] [snip console-output] Generating ojb repository descriptor (repository_user.xml) Type de.esw.services.server.ojb.Feature Processed 1 types Processed 1 types [/snip] Any idea what could be wrong? Thanks Markus Wolf -- emedia-solutions wolf Wedeler Landstrasse 63 22559 Hamburg (040) 550 083 70 web: http://www.emedia-solutions-wolf.de mail: [EMAIL PROTECTED] pgp: http://wwwkeys.de.pgp.net signature.asc Description: OpenPGP digital signature
Re: ojbdoclet and empty result files again
Could you please post the relevant part of the Feature class? Also, you could try running Maven in verbose or debug mode (I don't know anything about Maven, with Ant you would run it with the -v or -debug options). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ojbdoclet and empty result files again
Could you please post the relevant part of the Feature class? Also, you could try running Maven in verbose or debug mode (I don't know anything about Maven, with Ant you would run it with the -v or -debug options). I found my mistake. I've written @obj.class instead of @ojb.class in the doclet-tag. Sorry for inconvinience... Markus -- emedia-solutions wolf Wedeler Landstrasse 63 22559 Hamburg (040) 550 083 70 web: http://www.emedia-solutions-wolf.de mail: [EMAIL PROTECTED] pgp: http://wwwkeys.de.pgp.net signature.asc Description: OpenPGP digital signature
Re: composite foreign key references
How exactly is that supposed to work? I have a project and investigators. The project has id, lets say 13. I want all the investigators for project #13. I don't want to find the investigator w/ PK 13, so I can't use the PK from the investigator object...I have to use a different field called projectId (which is set access=anonymous because I don't need to store it in my object.) Maybe I don't understand hat you mean...can you explain some more? --Bobby Jakob Braeuchi wrote: bobby, suppose your inverse-foreign key definitions in project point to the pk-fields of investigator, do you still have the problem that the same value is used for both attributes ? i do not ecpect so. ojb 1.0.x assumes that the inverse-foreign key points to the pk of the referenced class. a more flexible handling of inverse-fk will be available in 1.1 jakob Bobby Lawrence schrieb: OJB 1.0.1 --B Jakob Braeuchi wrote: hi bobby, what version of ojb do you use ? jakob Bobby Lawrence schrieb: Armin- I can't use label as the key because to lookup a PI, I need the projectId and not the label. My problem is, OJB is using the value for projectId as the value for BOTH foreign keys (projectId and fiscalYear). Its not using the fiscalYear value in the query lookup. --Bobby Armin Waibel wrote: Bobby Lawrence wrote: Armin - I have to. I can a job table and a job class. The job table stores the project label. That is why it is listed as a primary key. I have to set it up this way. Can you help me with my problem? First, the PK declaration in OJB is independent from the PK declaration in your DB (but avoid constraint violations ;-)). OJB expects as FK fields in an object of a 1:n relation (PI) all PK fields of the main object (Project). In your case PI: fkFiscalYearId fkLabelId when Project has PK fiscalYear label collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=fkFiscalYearId / inverse-foreignkey field-ref=fkLabelId / /collection-descriptor HTH, Armin Armin Waibel wrote: Hi, Project --1:n -- PrimaryInvestigator (PI) PK fields for Project: label fiscalYears why is 'id' not the PK in Project? In PI FK are: projectId fiscalYear projectId id not a PK in Project, you have to use a 'labelId'. As a side-note, be really careful when using anonymous fields for fields other than 1:1 FK. http://db.apache.org/ojb/docu/guides/advanced-technique.html#How+do+ regards, Armin Bobby Lawrence wrote: Using the PersistenceBroker API... I have a class that has a 1:n relationship - a project can have many principal investigators. The class descriptors look like this: class-descriptor class=org.jlab.mis.services.mics.client.generated.Project table=projects field-descriptor name=id column=PROJECT_ID jdbc-type=VARCHAR/ field-descriptor name=label column=REPO_CODE jdbc-type=VARCHAR primarykey=true access=anonymous / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR primarykey=true / field-descriptor name=name column=PROJECT_NAME jdbc-type=VARCHAR / collection-descriptor name=primaryInvestigators element-class-ref=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator auto-retrieve=false inverse-foreignkey field-ref=projectId / inverse-foreignkey field-ref=fiscalYear / /collection-descriptor /class-descriptor class-descriptor class=org.jlab.mis.services.mics.client.generated.PrimaryInvestigator table=pis field-descriptor name=id column=PERSON_ID jdbc-type=VARCHAR primarykey=true/ field-descriptor name=firstName column=FIRSTNAME jdbc-type=VARCHAR / field-descriptor name=lastName column=LASTNAME jdbc-type=VARCHAR / field-descriptor name=email column=EMAIL jdbc-type=VARCHAR / field-descriptor name=fiscalYear column=FISCAL_YEAR jdbc-type=VARCHAR access=anonymous primarykey=true/ field-descriptor name=projectId column=PROJECT_ID jdbc-type=VARCHAR access=anonymous / /class-descriptor The problem is, whenever OJB tries to retrieve a collection of Primary Investigators, it never uses the correct value for the composite primary key. The debugging output looks like this: [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class org.jlab.mis.services.mics.client.generated.PrimaryInvestigator where [projectId = 13179, fiscalYear = 13179] As you can see, it is using the exact same value for the projectId and fiscalYear attributes. What am I doing wrong? - 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,
Re: ojbdoclet and empty result files again
No problem. On Mon, 14 Mar 2005 23:26:53 +0100, Markus Wolf [EMAIL PROTECTED] wrote: Could you please post the relevant part of the Feature class? Also, you could try running Maven in verbose or debug mode (I don't know anything about Maven, with Ant you would run it with the -v or -debug options). I found my mistake. I've written @obj.class instead of @ojb.class in the doclet-tag. Sorry for inconvinience... Markus -- emedia-solutions wolf Wedeler Landstrasse 63 22559 Hamburg (040) 550 083 70 web: http://www.emedia-solutions-wolf.de mail: [EMAIL PROTECTED] pgp: http://wwwkeys.de.pgp.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oracle 9i date-timestamp tip
Bruno CROS bruno.cros at gmail.com writes: it's important to note that mapping date attributes such as java.sql.Time java.util.Date (with hours ...) and even java.sql.Timestamp using DATE oracle type IS NOT POSSIBLE since Oracle 9.2 !! (Hours are lost ... with all it can occurs too !) FYI: we have patched the old Torque supplied with the OJB 1.0.x line of releases. In the upcoming OJB 1.0.2 there is a modified Torque JAR with a patched in profile oracle9 that can be used to make Torque generate TIMESTAMP correctly for all timestamp columns (as well as correct BLOB/CLOB mappings). In the OJB 1.1 line of releases OJB (and Torque) will use the DdlUtils [1] project for SQL-generation. Regards, Martin [1] Formerly know as commons-sql in the Apache Jakarta Sandbox, currently under migration to db.apache.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP, Oracle9i Blob/Clob broken
Danilo Tommasina dtommasina at risksys.com writes: When using the Oracle9i platform storing Blobs/Clobs does not work when using the DBCP connection factory (org.apache.ojb.broker.accesslayer.ConnectionFactoryDBCPImpl) Hi Danilo, thank you for your patch and suggestions. Unfortunately this is true not only for DBCP, but all types of wrapped connections (eg in managed environments like BEA WebLogic). And as you so carefully spotted, using P6Spy will render the same problem. BLOB/CLOB is only one out of two known issues with wrapped connections. The other one is batching and the 2k/4k BLOB/CLOB length limits with the oracle:thin driver. If you select batch-mode=true these annoying limits will reappear, even if using PlatformOracle9iImpl. (Another item on the TODO-list.) Previously there has been a special platform added to circument the wrapped connection problem (PlatformWLOracle9iImpl for WebLogic), but this solution is IMHO also not satisfactory due to code duplication and too many platforms. I reviewed your suggested DBCP-fix and this will not make it into the default Oracle9i platform, as the imports would add a DBCP run-time dependency when using OJB and Oracle9i platform (which is not currently the case and would apply even for users that don't want DBCP). I will try to make a more flexible support for all types of wrapped conenctions using reflection calls. If this is not possible your code could always extend the default platform and make a new PlatformDbcpOracle9iImp, but this would be my personal last choice... And one more side notice: why the Oracle and Sybase (and maybe other) platforms are not configured to use SQL92 syntax? Often this is simply because one developer adds a new platform method and do not have access to all RDBMS that OJB support, and therefore have to make a qualified guess for good defaults. If no-one using a specific platform yells this can go unnoticed for some time... At least in Sybase there are less limitations on outer joins when using this syntax and it should be granted that you get same results on all platform when using the SQL92. Agreed. Since Oracle9i passes all regression tests regardless of ORACLE/SQL92 join syntax I added your suggestion to CVS (for both 1.0.x branch and HEAD). The upcoming OJB 1.0.2 release will use SQL92 join syntax for the Oracle9i platform. (Sybase is unknown territory for me.) Regards, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: xdoclet: generate interface descriptor
I'm not sure I understand what you saying here, but FYI, I'm currently changing the XDoclet module to * allow the generation of complete class-descriptors (in the sense that they have field/resource/collection descriptors) without a table * automatic include primary/foreign keys from subtypes into their basetype if this basetype is referenced by a reference/collection but does not declare these keys itself Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oracle Driver jdbc10.1.0.2
Thierry Hanot wrote: Hello All just for info. It does not look like bug but more like a small missing feature :) . A support of Oracle thin driver 10 does not exist in Ojb. It could be nice to have it in Obj 1.0 because normally ( just reading the documentation ) , there is is a lot of performance improvement on those drivers. Thanks for testing Thierry, Oracle 10g JDBC support is now in CVS and should be available with the upcoming OJB 1.0.2 release. Tested with ojdbc14.jar from Oracle 10.1.0.2.0 with a 9iR2 RDBMS, as of yet untested with v10 on the server-side as well. Please re-test if possible. Regards, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Oracle Driver jdbc10.1.0.2
Dougall Squair wrote: Are you running within a managed environment? We seem to be getting a similar exception when we use the Oracle9i platform support class, I suspect it's caused by WebLogic wrapping the Oracle connection object. Generic unwrapping of both Connection and PreparedStatement have been added to the PlatformOracle9iImpl. Current implementation knows about Oracle10g, BEA WebLogic, Apache Commons DBCP and P6spy wrappers. The PlatformWLOracle9iImpl has been marked as deprecated, as the standard platform should work also in BEA WebLogic. If unwrapping fails, the 9i platform is still usable (but has the 2k/4k BLOB/CLOB limits and no ORA performance-extensions activated). This is in CVS now and should be available with the upcoming OJB 1.0.2 release. Please re-test if possible. Regards, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: May Be a Problem with Lob reader ????
Thierry Hanot wrote: Hello , i have a problem when loading some data from blob. I use the standard support of lob in plateform Oracle 9i. The problem is when i try to load object with a blob in different Thread. I request a broker from thread 1 for loading objects with lob. I request an other broker from thread 2 for loading other objects. Using a Connection pool the same connection is used by the 2 Threads ( It does not happen all the time ). It's probably an oracle bug/limitation but when a try to iterate on a result set in thread 2 in the same time a blob is read in thread 1 there is a dead lock. Thread 1 = OracleConnection.needLineThread2 = OraclePreparedStatement.init() ( =TTC7.getVersionNumber() ). Is there a simple way in obj to force a broker to use a new connection for loading data ??? The PB-API is not thread safe and must be externally synchronized. If you use one PersistenceBroker per thread you should not see these deadlocks. Please report back if you have any new findings. Regards, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
