Re: StringIndexOutOfBoundsException at SqlHelper.splitPath
Thanks Armin,
But, that was another problem.
That was caused by below line in my code.
query.addGroupBy("DATE_FORMAT(DATE, \"%Y/%m/%d\")");
# DATE_FORMAT() is mysql function
And SqlHelper.java:
colName = betweenBraces.substring(colBegin + 1, colEnd);
colBegin is created by..
colBegin = betweenBraces.indexOf(" ");
So, colBegin will be 5 with aPath="DATE_FORMAT(DATE, \"%Y/%m/%d\")" .
And colEnd indicates ","'s place. then colEnd is 4.
SqlHelper will try substring with condition colBeling > colEnd.
That is the problem.
Just for me, removing white space from above query is enough.
But I want you to fix it.
I wanted to write a patch, but I don't know expected work of SqlHelper.
Thanks.
On Friday 06 February 2004 20:14, Armin Waibel wrote:
> Hi,
>
> I think (but I'm not sure) this is fixed in CVS HEAD (not 1.0_branch).
> See
> http://www.mail-archive.com/ojb-user%40db.apache.org/msg07835.html
>
> regards,
> Armin
>
> shivaken wrote:
> > Hi,
> >
> > At imigrating to rc5 from rc4, I got StringIndexOutOfBoundsException.
> > I read SqlHelper.java. But I couldn't find any wrong thing.
> >
> > Please help me.
> >
> > # I'm using J2sdk1.4.2_03, db-ojb-rc5
> >
> > # I did
> > Criteria criteria = new Criteria();
> > String[] columns = { "sum(TIME)" };
> > QueryByCriteria query =
> > new ReportQueryByCriteria(Call.class, columns, criteria);
> > query.addGroupBy("DATE_FORMAT(DATE, \"%Y/%m/%d\")");
> >
> > # stack trace
> > java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> > at java.lang.String.substring(String.java:1444)
> > at org.apache.ojb.broker.util.SqlHelper.splitPath(Unknown Source)
> > at
> > org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.getAttributeI\
> > nfo(Unknown Source)
> > at
> > org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.appendColName\
> > (Unknown Source)
> > at
> > org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement.ensureColumns\
> > (Unknown Source)
> > at
> > org.apache.ojb.broker.accesslayer.sql.SqlSelectStatement.getStatement\
> > (Unknown Source)
> > at
> > org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.getPrep\
> > aredSelectStatement(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.(Unknown
> > Source) at
> > org.apache.ojb.broker.accesslayer.ReportQueryRsIterator.(Unknow\
> > n Source)
> > at
> > org.apache.ojb.broker.core.ReportRsIteratorFactoryImpl.createRsIterat\
> > or(Unknown Source)
> > at
> > org.apache.ojb.broker.core.PersistenceBrokerImpl.getRsIteratorFromQue\
> > ry(Unknown Source)
> > at
> > org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIterat\
> > orFromQuery(Unknown Source)
> > at
> > org.apache.ojb.broker.core.PersistenceBrokerImpl.getReportQueryIterat\
> > orByQuery(Unknown Source)
> > at
> > org.apache.ojb.broker.core.DelegatingPersistenceBroker.getReportQuery\
> > IteratorByQuery(Unknown Source)
> > at
> > org.apache.ojb.broker.core.DelegatingPersistenceBroker.getReportQuery\
> > IteratorByQuery(Unknown Source)
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
-- shivaken
antshell: Ant command line front end
http://www.antshell.org
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Transaction Question.
Hi, There can only be one ODMG transaction open per thread. Thanks, Rob :) > -Original Message- > From: Ziv Yankowitz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, 10 February 2004 5:39 a.m. > To: OJB (E-mail) > Subject: Transaction Question. > > > Folks, > > Is Nested Transaction supported within ODMG? > > assuming we have the following : > > within the same Thread. > > Transaction1 start > Transaction2 start > Transaction2 finish > Transaction1 finish. > > Thanks. > > > - > 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]
FW: This looks like a bug in store()
Richard,
You might try setting up the reference as a proxy and then create a
proxy object and set the identity on it. This way your object model
would not be out of synch with your database. I'm not sure if OJB is
going to try to materialize the proxy on store though.
Maybe one of the developers can comment further on this. I.E. How
concrete is the proxy implementation? Does a factory exist to create a
proxy object when given an Identity object? Does OJB try to materialize
a proxy on store?
Wally
-Original Message-
From: Richard Schuller [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 1:42 PM
To: OJB Users List
Cc: Gelhar, Wallace Joseph
Subject: RE: This looks like a bug in store()
Thanks Gelhar,
While that works it results into an unnecessary
database call. Is there a way to bypass this
behaviour?
Richard
--- "Gelhar, Wallace Joseph" <[EMAIL PROTECTED]>
wrote:
> Hi Richard,
>
> This is not a bug, but rather behavior by design.
>
> OJB is an object level mapping layer. Therefore, OJB
> is using the value
> of the reference object you set (null!) and updating
> the FK (i.e.
> clearing the field). If you first set the FK and
> want to resolve the
> object, you may call pb.retrieveReference("referenceAttribute"); to
> load the object before storing.
>
> Hope this helps.
>
> Wally
>
> -Original Message-
> From: Richard Schuller [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 09, 2004 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: This looks like a bug in store()
>
>
> I have a class A representing table TA defined as
> follows:
>
> class A {
>
> private Long sourceId;
> private Long targetId;
> ...
> TCorporation source;
> TCorporation target;
> }
>
> If I set the sourceId to new Long(1234) and
> source=null the INSERT statement generated blanks
> out
> the source id.
>
> Anybody else ran into this?
>
> Richard
>
>
>
> __
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing
> online.
> http://taxes.yahoo.com/filing.html
>
>
-
> 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]
>
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: This looks like a bug in store()
Hi Richard,
Richard Schuller wrote:
Thanks Gelhar,
While that works it results into an unnecessary
database call. Is there a way to bypass this
behaviour?
Latest version from CVS has some improvements on object insert, e.g. now
it is allowed to insert a new object only with reference id set (and
reference object null). But only for insert!
>>If I set the sourceId to new Long(1234) and
>>source=null the INSERT statement generated blanks
Should work with latest from CVS.
regards,
Armin
Richard
--- "Gelhar, Wallace Joseph" <[EMAIL PROTECTED]>
wrote:
Hi Richard,
This is not a bug, but rather behavior by design.
OJB is an object level mapping layer. Therefore, OJB
is using the value
of the reference object you set (null!) and updating
the FK (i.e.
clearing the field). If you first set the FK and
want to resolve the
object, you may call
pb.retrieveReference("referenceAttribute"); to load
the object before storing.
Hope this helps.
Wally
-Original Message-
From: Richard Schuller [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 1:20 PM
To: [EMAIL PROTECTED]
Subject: This looks like a bug in store()
I have a class A representing table TA defined as
follows:
class A {
private Long sourceId;
private Long targetId;
...
TCorporation source;
TCorporation target;
}
If I set the sourceId to new Long(1234) and
source=null the INSERT statement generated blanks
out
the source id.
Anybody else ran into this?
Richard
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing
online.
http://taxes.yahoo.com/filing.html
-
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]
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
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: This looks like a bug in store()
Thanks Gelhar,
While that works it results into an unnecessary
database call. Is there a way to bypass this
behaviour?
Richard
--- "Gelhar, Wallace Joseph" <[EMAIL PROTECTED]>
wrote:
> Hi Richard,
>
> This is not a bug, but rather behavior by design.
>
> OJB is an object level mapping layer. Therefore, OJB
> is using the value
> of the reference object you set (null!) and updating
> the FK (i.e.
> clearing the field). If you first set the FK and
> want to resolve the
> object, you may call
> pb.retrieveReference("referenceAttribute"); to load
> the object before storing.
>
> Hope this helps.
>
> Wally
>
> -Original Message-
> From: Richard Schuller [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 09, 2004 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: This looks like a bug in store()
>
>
> I have a class A representing table TA defined as
> follows:
>
> class A {
>
> private Long sourceId;
> private Long targetId;
> ...
> TCorporation source;
> TCorporation target;
> }
>
> If I set the sourceId to new Long(1234) and
> source=null the INSERT statement generated blanks
> out
> the source id.
>
> Anybody else ran into this?
>
> Richard
>
>
>
> __
> Do you Yahoo!?
> Yahoo! Finance: Get your refund fast by filing
> online.
> http://taxes.yahoo.com/filing.html
>
>
-
> 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]
>
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: This looks like a bug in store()
Hi Richard,
This is not a bug, but rather behavior by design.
OJB is an object level mapping layer. Therefore, OJB is using the value
of the reference object you set (null!) and updating the FK (i.e.
clearing the field). If you first set the FK and want to resolve the
object, you may call pb.retrieveReference("referenceAttribute"); to load
the object before storing.
Hope this helps.
Wally
-Original Message-
From: Richard Schuller [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 1:20 PM
To: [EMAIL PROTECTED]
Subject: This looks like a bug in store()
I have a class A representing table TA defined as
follows:
class A {
private Long sourceId;
private Long targetId;
...
TCorporation source;
TCorporation target;
}
If I set the sourceId to new Long(1234) and
source=null the INSERT statement generated blanks out
the source id.
Anybody else ran into this?
Richard
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
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: GroupBy clause ignored in PersistentBroker.getCount( Query query)
hi danilo,
Danilo Tommasina wrote:
Hi Jakob,
yup I tried to 'patch' the getCount() method and also saw that setting
the copy-groupBy flag to true wouldn't solve the problem.
copying the 'group by' information may be done by iterating on the
results of the Query.getGroubBy() and adding the columns to the report
query.
that's what i've done.
however, this doesn't return me what i really expected (on sybase) since
it returns me several rows containing the count of the elements
available in the 'groups' and not the total number of grouped results.
Actually the number i would expect may be extracted counting the rows in
the count-query resultset.
However i don't know if every db does the count the same manner as
sybase, so this may not be a viable solution.
actually for 'real' databases (also not sybase) it is possible to use a
ditinct clause for doing exactly what i need, however scheissbase <=
this isn't the official name, isn't it ;)
12.0 knows only VARCHAR with a max length of 255, so for longer texts a
data type TEXT (a CLOB) must be used. of course no distinct query can be
done if a table contains TEXT fields.
the horrible trick to simulate a distinct query in sybase is this (for
anyone interested in it):
in case the platform contains the string 'sybase' then instead of
setting the distinct flag, add a group by clause for the PK.
(this is supported by sybase, but will fail on oracle)
drawback is that a count query on this fake distinct query will return
wrong results. and here comes the second horrible trick.
since ojb ignores the group by clause and a OJB distinct count query
adds the distinct clause only on PK columns (that should never be of
type TEXT) then it is possible to safely set the 'distinct' flag for the
count query also for sybase.
so for doing a 'results count limited distinct query' i do the following
(for sybase):
- set the distinct flag on query
- do count query
- if count > than maximum results throw exception
- else reset the distinct flag
- add group by for the PK
- do the query
brr, horrible but works
i was thinking of:
select count (distinct key1 || key2) from when we have multiple pks.
this does of course not solve the group by at all :( and of course string
concatenation is not the same on any platform (|| is the ansi char for
concatenation, but ms sql-server uses +, ms-access &, mysql has a function
called concat...) how is it in s...base ?
imo an easy way to solve the problems would be to use an enclosing count query:
select count(*) from (original query)
but this does not yet work in mysql !
so, sorry for the long text, but maybe sombody else has the same problem
and that's the (horrible) way i solved it.
if somebody has a better solution i would be glad to hear it, thanks
anyway
cheers
danilo
jakob
hi danilo,
the groupBy information is defined in the query not in the criteria,
so the copy() does not make much sense. but there's a problem when
counting reportqueries using groupBy:
Criteria crit = new Criteria();
ReportQueryByCriteria q =
QueryFactory.newReportQuery(ProductGroup.class, crit);
q.setColumns(new String[] { "groupName",
"sum(allArticlesInGroup.stock)", "sum(allArticlesInGroup.price)" });
q.addGroupBy("groupName");
broker.getReportQueryIteratorByQuery(q);
while (iter.hasNext())
{
results.add(iter.next());
}
int count = broker.getCount(q);
assertEquals(results.size(), count); <<< FAILS
results in this sql:
SELECT A0.KategorieName,sum(A1.Lagerbestand),sum(A1.Einzelpreis)
FROM Kategorien A0
LEFT OUTER JOIN BOOKS A1 ON A0.Kategorie_Nr=A1.Kategorie_Nr
LEFT OUTER JOIN CDS A1E2 ON A0.Kategorie_Nr=A1E2.Kategorie_Nr
LEFT OUTER JOIN Artikel A1E1 ON A0.Kategorie_Nr=A1E1.Kategorie_Nr
GROUP BY A0.KategorieName
ojb generates a wrong count-sql :
SELECT count(*) FROM Kategorien A0
or when including groupBy:
SELECT count(*),A0.KategorieName as ojb_col_1 FROM Kategorien A0 GROUP
BY A0.KategorieName
how should the count look like (without using a subquery) ?
jakob
Danilo Tommasina wrote:
Hi,
Is there a reason why the GroupBy clause is beeing ignored in a query
when doing a PersistenceBorker.getCount( Query query )?
In RC4 release I found this piece of code:
class PersistenceBokerImpl
public int getCount(Query query) throws PersistenceBrokerException
{
(...)
// build a ReportQuery based on query
// orderby needs to be cleared
if (query.getCriteria() != null)
{
reportCrit = query.getCriteria().copy(false, false, false);
}
(...)
}
The line:
reportCrit = query.getCriteria().copy(false, false, false);
copies the Criteria ignoring the GroupBy clause, thus causing the
count query to return a wrong number of elements.
Is there a reason for this or has it been fixed after RC4?
thx
bye Danilo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTE
This looks like a bug in store()
I have a class A representing table TA defined as
follows:
class A {
private Long sourceId;
private Long targetId;
...
TCorporation source;
TCorporation target;
}
If I set the sourceId to new Long(1234) and
source=null the INSERT statement generated blanks out
the source id.
Anybody else ran into this?
Richard
__
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inner Join on separate data bases
Sorry, that is supposed to be "inner join on separate data bases". D'oh. Charlie Charles N. Harvey III wrote: Hello. I was wondering if it was possible to join two objects that are mapped to two separate DBs. SELECT p.name, p.email, e.title, e.position FROM users.dbo.PERSON AS p INNER JOIN office.dbo.EMPLOYEES AS e ON e.employee_id = p.person_id WHERE e.title = 'Manager' I have two connection descriptors in my repository.xml. Should I change the table="EMPLOYEE" with table="office.dbo.EMPLOYEE"? Can this be done. There is a very good chance that my mappings are not done correctly. Any help is much appreciated. Charlie - 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]
Inner Join on separate tables
Hello. I was wondering if it was possible to join two objects that are mapped to two separate DBs. SELECT p.name, p.email, e.title, e.position FROM users.dbo.PERSON AS p INNER JOIN office.dbo.EMPLOYEES AS e ON e.employee_id = p.person_id WHERE e.title = 'Manager' I have two connection descriptors in my repository.xml. Should I change the table="EMPLOYEE" with table="office.dbo.EMPLOYEE"? Can this be done. There is a very good chance that my mappings are not done correctly. Any help is much appreciated. Charlie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help, I'm stuck and I can't get out! (Infinite Loop)
It isn't a bug. Actually, it's a "Feature by design". Since I don't maintain cache of objects (this is the behaviour of EmptyCache), there is no way to know that the object is loaded. So it will load. If the loaded object has references to the first object, it will load the first object again, and so on. In the circunstances where I can't avoid two way navigable references, I use object-cache tag per object. In all other places I work with EmptyCache and there is no problem. Thats my experience, and may not be true for rc5, since I working with some outdated HEAD rc4. Best regards, Edson Richter > For the slow people in the class, can you please explain this problem in > a little more detail? If I have to tweak cache timeouts to get correct > behavior on simple references, then there 's a bug hiding in here somewhere. > > Thanks. > > Edson Carlos Ericksson Richter wrote: > >>Exists some circustantes that results in infinite loop due to use of EmptyCache with >>two >> way navigable references. Are you using this? If yes, try to set a >> in the >> recerenced bean with a very low time-out (let's say, 1 sec). It solved almost vast >> majority >> of my cases. >> >>Best regards, >> >>Edson Richter >> >> - Original Message - >> From: Clay Mitchell >> To: OJB Users List >> Sent: Saturday, February 07, 2004 2:16 PM >> Subject: Help, I'm stuck and I can't get out! (Infinite Loop) >> >> >> I seem to have gotten myself stuck in a infinite loop here... >> >> Any idea what it's doing and why? >> >> Thanks >> -Clay >> >> [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: >> getCollectionByQuery (class >> org.apache.ojb.broker.util.collections.RemovalAwareCollection, class >> com.exigentic.onyx.ProductType, Query from class >> com.exigentic.onyx.ProductType where [id IN [79, 28, 112]]) >> [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] >> DEBUG: TableAlias(): using hints ? false >> >> [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: >> getCollectionByQuery (class >> org.apache.ojb.broker.util.collections.RemovalAwareCollection, class >> com.exigentic.onyx.Specification, Query from class >> com.exigentic.onyx.Specification where [id IN [79, 28, 112]]) >> [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] >> DEBUG: TableAlias(): using hints ? false >> >> [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: >> getCollectionByQuery (class >> org.apache.ojb.broker.util.collections.RemovalAwareCollection, class >> com.exigentic.onyx.Product, Query from class com.exigentic.onyx.Product >> where [id IN [79, 28, 112]]) >> [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] >> DEBUG: TableAlias(): using hints ? false >> >> [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: >> getCollectionByQuery (class >> org.apache.ojb.broker.util.collections.RemovalAwareCollection, class >> com.exigentic.onyx.SpecType, Query from class >> com.exigentic.onyx.SpecType where [id IN [79, 28, 112]]) >> [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] >> DEBUG: TableAlias(): using hints ? false >> >> [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: >> getCollectionByQuery (class >> org.apache.ojb.broker.util.collections.RemovalAwareCollection, class >> com.exigentic.onyx.Specification, Query from class >> com.exigentic.onyx.Specification where [specId = 28]) >> [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] >> DEBUG: TableAlias(): using hints ? false >> >> >> ## Here's my repository: >> >> >> >> > Foundation//DTD OJB Repository//EN" "repository.dtd"> >> >> >> > default-connection="true" platform="PostgreSQL" jdbc-level="3.0" >> driver="org.postgresql.Driver" protocol="jdbc" subprotocol="postgresql" >> dbalias="//192.168.1.101:5432/onyx" username="postgres" >> password="t30a6az8z" eager-release="false" batch-mode="false" >> useAutoCommit="1" ignoreAutoCommitExceptions="false"> >> >> > className="org.apache.ojb.broker.util.sequence.SequenceManagerNextValImpl"> >> >> >> >> >> > autoincrement="true" sequence-name="account_seq'::text" >> column="ACCOUNT_ID" jdbc-type="INTEGER"/> >> > column="EMAIL" jdbc-type="VARCHAR"/> >> > default-fetch="true" column="PASSWORD" jdbc-type="VARCHAR"/> >> > default-fetch="true" column="NAME_FIRST" jdbc-type="VARCHAR"/> >> > default-fetch="true" column="NAME_LAST" jdbc-type="VARCHAR"/> >> > jdbc-type="VARCHAR"/> >> > column="PHONE" jdbc-type="VARCHAR"/> >> > jdbc-type="VARCHAR"/> >> > column="ADDR_1" jdbc-type="VARCHAR"/> >> > jdbc-type="VARCHAR"/> >> > column="CITY" jdbc-type="VARCHAR"/> >> > column="STATE" jdbc-type="VARCHAR"/> >> > column="COUNTRY" jdbc-type="VARCHAR"/> >> > column="ZIP" jdbc-type="VARCHAR"/> >> > default-fetch="true" column="SECURITY" jdbc-type="INTEGER"/> >> > default-fetch="true" column="SOURCE_DATE" jdbc-type="TIMESTAMP" >> >> conversion="org.ap
Re: JDO Collections
> Oh yes the certainly can be a good idea. I'm not against this, but with > no current java mechanism for automatically enforcing this sort of > thing, effort/time must be expended to enforce it manually, and thus I > would only do it where it appears to be critical (such as an obvious way > that wrong types could hit the collection and an exception should be > thrown), or provide some form of optimization if that optimization is > needed. In this case, I will do it to make OJB's jdori plug-in happy. It > will be interesting to see if/how how JDO is effected by the 1.5 > generics you describe. It sounds like the metadata would have to become > non-optional in some cases. Or vice versa superfluous as already present in the java type (generics). I'll also be very interested in seeing how Java 1.5 affects OJB ;-) Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Collections
This is not necessarily an optimization but rather a removal of unnecessary genericity. Let me explain: in java when you use a collection, you simply say all objects in it are of type Object or subtypes thereof. This may be well but usually you only mean to put objects of type SomeBaseType or subtypes of it, into the collection. So why not using the ability of a compiler to check that you don't put objects of other types in it by accident (this is called generic types and will be available in Java 1.5 btw). Oh yes the certainly can be a good idea. I'm not against this, but with no current java mechanism for automatically enforcing this sort of thing, effort/time must be expended to enforce it manually, and thus I would only do it where it appears to be critical (such as an obvious way that wrong types could hit the collection and an exception should be thrown), or provide some form of optimization if that optimization is needed. In this case, I will do it to make OJB's jdori plug-in happy. It will be interesting to see if/how how JDO is effected by the 1.5 generics you describe. It sounds like the metadata would have to become non-optional in some cases. In JDO it is similar to Java (well actually it is the same): it is usually better though less convenient to have associations as un-generic as possible. Though here it may be more of performance reasons than static type-checking. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Query Performance
SO all you can do for the moment is to wait for our own full JDO implementation that will not have such limitations. So when does this start? In fact it has already started. Have a look at the folder src/java/org/apache/ojb/jdo in the source distribution. This new implementation is a thin layer on top of the OTM API. SOme things are still missing: 1. a JDOQL Parser 2. a bytecode enhancer 3. an extension to the repositoryPersistor that allows to use a .JDO file instead of a repository.xml Cool. I'll peek at it some time, like maybe tonight or next weekend 1 and 3 look interesting. I know nothing about bytecode however... What about an xdoclet based source code enhancer as an additional option? what java version compatability do you need to maintain for ojb stuff? Do you have a developer doc that has all those details somewhere? I hope it's not 1.1, I hate working with enumerations :). Will it use the current JDO related classes or rewrite them? It will be a complete rewrite, as we won't rely on the JDORI any longer... ok so the migration from the jdori based stuff to the native stuff will probably not be trivial then... I hope the jdori based version will be maintained for those who are using it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help, I'm stuck and I can't get out! (Infinite Loop)
For the slow people in the class, can you please explain this problem in a little more detail? If I have to tweak cache timeouts to get correct behavior on simple references, then there 's a bug hiding in here somewhere. Thanks. Edson Carlos Ericksson Richter wrote: Exists some circustantes that results in infinite loop due to use of EmptyCache with two way navigable references. Are you using this? If yes, try to set a in the recerenced bean with a very low time-out (let's say, 1 sec). It solved almost vast majority of my cases. Best regards, Edson Richter - Original Message - From: Clay Mitchell To: OJB Users List Sent: Saturday, February 07, 2004 2:16 PM Subject: Help, I'm stuck and I can't get out! (Infinite Loop) I seem to have gotten myself stuck in a infinite loop here... Any idea what it's doing and why? Thanks -Clay [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.ProductType, Query from class com.exigentic.onyx.ProductType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Product, Query from class com.exigentic.onyx.Product where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.SpecType, Query from class com.exigentic.onyx.SpecType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [specId = 28]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false ## Here's my repository: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 3/2/2004 -- Larry V. Streepy, Jr. Senior Vice President and CTO Health Langugae, Inc.
Re: JDO Collections
On Mon, 9 Feb 2004, Gus Heck wrote: > According to the book I have (which is not the spec, but hopefully the > author has read and understood the spec) it has the following example: > > > > > > > > > > > > > > This looks like what you are describing, but underneath that with a bold > heading is this: > > Additional Metadata > > The additional metadata shown for the "books" filed is optional; it > does not need to be specified. If not specified the JDO runtime assumes > that the colledtion may contain a reference to any persistent object, as > does normal Java. > Even though it is optional it is best practice to define the element > type of a collection because it potentially allows the JDO runtime ot > optimize how it handles the field both in-memory as well as in the > datastore. The spec certainly has object-oriented or object-based databases/repositories in mind which probably store the associations explicitly. In OJB this (currently) can only be achieved via the indirection table. However this requires either one table for each type pair of the ends of the association, or the definition of the association between base types of the possible objects at both ends. As the first way is pretty difficult to handle, my guess is that for the combination OJB+JDO you currently need this - for the spec - optional data. Perhaps some JDO expert can hop in and explain in more detail. > From this it looks like "PersistenceCapable" is supposed to be the > default common base type. So for my project, given the current OJB > implementation is not the final implementation and it seems in this > respect incomplete, I will probably just have to work around this. It > probably isn't too hard as I look at my object model, but I was going to > relegate this to "Optimize Last." This is not necessarily an optimization but rather a removal of unnecessary genericity. Let me explain: in java when you use a collection, you simply say all objects in it are of type Object or subtypes thereof. This may be well but usually you only mean to put objects of type SomeBaseType or subtypes of it, into the collection. So why not using the ability of a compiler to check that you don't put objects of other types in it by accident (this is called generic types and will be available in Java 1.5 btw). In JDO it is similar to Java (well actually it is the same): it is usually better though less convenient to have associations as un-generic as possible. Though here it may be more of performance reasons than static type-checking. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Transaction Question.
Folks, Is Nested Transaction supported within ODMG? assuming we have the following : within the same Thread. Transaction1 start Transaction2 start Transaction2 finish Transaction1 finish. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDO Query Performance
Hi Gus, > -Original Message- > From: Gus Heck [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 4:42 PM > To: OJB Users List > Subject: Re: JDO Query Performance > > > > > > > SO all you can do for the moment is to wait for our own full JDO > > implementation that will not have such limitations. > > > So when does this start? In fact it has already started. Have a look at the folder src/java/org/apache/ojb/jdo in the source distribution. This new implementation is a thin layer on top of the OTM API. SOme things are still missing: 1. a JDOQL Parser 2. a bytecode enhancer 3. an extension to the repositoryPersistor that allows to use a .JDO file instead of a repository.xml > Will it use the current JDO related > classes or > rewrite them? It will be a complete rewrite, as we won't rely on the JDORI any longer... > I might be interested in pitching in, a bit > when it does > if I can find a small chunk or two to work on. (I probably can't do a > whole lot of work, but it would be fun to help to some extent). > That would be great, all help is welcome! Maybe you just have look at the existing code and check if you find a spot that you'd like to work on... cu, Thomas > -Gus > > > - > 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: Transaction Problem.
Hi, "If you use Identity queries you will load objects from the cache. But if you use criteria based queries an SQL query is executed against the DB." If I under stand correct then even if I use Identity it won't work because the data is not in the cache until commit is done. Thanks. -Original Message- From: Mahler Thomas [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 5:41 PM To: 'OJB Users List' Subject: RE: Transaction Problem. If you use Identity queries you will load objects from the cache. But if you use criteria based queries an SQL query is executed against the DB. > -Original Message- > From: Ziv Yankowitz [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 4:34 PM > To: OJB Users List; [EMAIL PROTECTED] > Subject: RE: Transaction Problem. > > > Hi, > > Armin wrote: > > > No, problem is when object was only pushed to cache it's > not possible to > > query the object and you run into the same problem as before.Thanks. > > If I under stand correctly then using query by Identity with > the Broker Api will first query the cache, so if the object > was cached I could retrieve it. > > is there some way I could use it? > > Thanks Again for the reponses, > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 5:08 PM > To: OJB Users List > Subject: Re: Transaction Problem. > > > Hi, > > Ziv Yankowitz wrote: > > > Hi, > > > > Thanks for the response. > > > > if I understand correctly the flush writes the object to > the db and cache. > > yep! > > > Is there a way to write only to the cache and not to the db > and then when commit accurse the db will be hit. > > No, problem is when object was only pushed to cache it's not > possible to > query the object and you run into the same problem as before. > > regards, > Armin > > > > > Thanks. > > > > -Original Message- > > From: Armin Waibel [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 09, 2004 4:59 PM > > To: OJB Users List > > Subject: Re: Transaction Problem. > > > > > > Hi, > > > > Ziv Yankowitz wrote: > > > >>Folks, > >> > >>I'm using ODMG API . > >> > >>I'm trying to insert an object and query the object in the > same transaction before the object was committed is this possible. > > > > > > You have to use a proprietary extension method of Transaction: > > ((TransactionExt) tx).flush() > > > > regards, > > Armin > > > > > >>thanks. > >> > >> > - > >>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] > - 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: Transaction Problem.
If you use Identity queries you will load objects from the cache. But if you use criteria based queries an SQL query is executed against the DB. > -Original Message- > From: Ziv Yankowitz [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 4:34 PM > To: OJB Users List; [EMAIL PROTECTED] > Subject: RE: Transaction Problem. > > > Hi, > > Armin wrote: > > > No, problem is when object was only pushed to cache it's > not possible to > > query the object and you run into the same problem as before.Thanks. > > If I under stand correctly then using query by Identity with > the Broker Api will first query the cache, so if the object > was cached I could retrieve it. > > is there some way I could use it? > > Thanks Again for the reponses, > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 5:08 PM > To: OJB Users List > Subject: Re: Transaction Problem. > > > Hi, > > Ziv Yankowitz wrote: > > > Hi, > > > > Thanks for the response. > > > > if I understand correctly the flush writes the object to > the db and cache. > > yep! > > > Is there a way to write only to the cache and not to the db > and then when commit accurse the db will be hit. > > No, problem is when object was only pushed to cache it's not > possible to > query the object and you run into the same problem as before. > > regards, > Armin > > > > > Thanks. > > > > -Original Message- > > From: Armin Waibel [mailto:[EMAIL PROTECTED] > > Sent: Monday, February 09, 2004 4:59 PM > > To: OJB Users List > > Subject: Re: Transaction Problem. > > > > > > Hi, > > > > Ziv Yankowitz wrote: > > > >>Folks, > >> > >>I'm using ODMG API . > >> > >>I'm trying to insert an object and query the object in the > same transaction before the object was committed is this possible. > > > > > > You have to use a proprietary extension method of Transaction: > > ((TransactionExt) tx).flush() > > > > regards, > > Armin > > > > > >>thanks. > >> > >> > - > >>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] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Collections
So does this mean I can only have collections of a specific element type? What about collections that hold multiple types? Is it impossible to store them? I think that specification of element types is supposed to be optional for JDO. (allowing the implementation to optimize if it is specified) In normal OJB (PB, ODMG) you specify 1:n associations (references), 1:n and m:n associations (colletions) between persistent classes (types that have a class descriptor). If you want a somewhat generic collection you have to find a common basetype of all possible element objects, which can be made persistent. Especially it needs to have primary keys. I don't know anything about JDO, but I guess it is the same there. Tom According to the book I have (which is not the spec, but hopefully the author has read and understood the spec) it has the following example: This looks like what you are describing, but underneath that with a bold heading is this: Additional Metadata The additional metadata shown for the "books" filed is optional; it does not need to be specified. If not specified the JDO runtime assumes that the colledtion may contain a reference to any persistent object, as does normal Java. Even though it is optional it is best practice to define the element type of a collection because it potentially allows the JDO runtime ot optimize how it handles the field both in-memory as well as in the datastore. From this it looks like "PersistenceCapable" is supposed to be the default common base type. So for my project, given the current OJB implementation is not the final implementation and it seems in this respect incomplete, I will probably just have to work around this. It probably isn't too hard as I look at my object model, but I was going to relegate this to "Optimize Last." It looks like this typeless collection issue is something to think about for the final native JDO implementation. By the way does any1 know when work on the full native implementation is going to start? will it continue with the same classes and just work to replace the Sun dependancies, or will it be re-done from scratch? -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Query Performance
SO all you can do for the moment is to wait for our own full JDO implementation that will not have such limitations. So when does this start? Will it use the current JDO related classes or rewrite them? I might be interested in pitching in, a bit when it does if I can find a small chunk or two to work on. (I probably can't do a whole lot of work, but it would be fun to help to some extent). -Gus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Transaction Problem.
Hi again, Ziv Yankowitz wrote: Hi, Armin wrote: No, problem is when object was only pushed to cache it's not possible to query the object and you run into the same problem as before.Thanks. If I under stand correctly then using query by Identity with the Broker Api will first query the cache, so if the object was cached I could retrieve it. That's right, but AFAIK odmg-api does not use this feature of PB-api when build an OQLQuery and what to do when user enable ObjectCacheEmptyImpl? is there some way I could use it? sorry I assume no, if you need such an feature you have to do this by your own. regards, Armin Thanks Again for the reponses, -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 5:08 PM To: OJB Users List Subject: Re: Transaction Problem. Hi, Ziv Yankowitz wrote: Hi, Thanks for the response. if I understand correctly the flush writes the object to the db and cache. yep! Is there a way to write only to the cache and not to the db and then when commit accurse the db will be hit. No, problem is when object was only pushed to cache it's not possible to query the object and you run into the same problem as before. regards, Armin Thanks. -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 4:59 PM To: OJB Users List Subject: Re: Transaction Problem. Hi, Ziv Yankowitz wrote: Folks, I'm using ODMG API . I'm trying to insert an object and query the object in the same transaction before the object was committed is this possible. You have to use a proprietary extension method of Transaction: ((TransactionExt) tx).flush() regards, Armin thanks. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: foreign key is not being updated...
Wally you are a live saver!!! I just forgot to set the reference object
person in class activity. Now it works! thanks for your hint.
-Ursprüngliche Nachricht-
Von: Gelhar, Wallace Joseph [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 9. Februar 2004 15:27
An: OJB Users List
Betreff: RE: foreign key is not being updated...
Vertraulichkeit: Persönlich
Hi Dirk,
It looks like you are setting the FK and not the reference object.
Therefore, on an update, OJB is resolving and updating the FK of the set
reference object (null!). If you want to continue setting the FK, you must
call pb.resolveReference("reference"); to set the object prior to the store
call.
Hope this helps,
Wally
-Original Message-
From: Dirk Manske (Service Respond)
[mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 5:38 AM
To: 'OJB Users List'
Subject: AW: foreign key is not being updated...
Sensitivity: Personal
I am still struggling to update a foreign key (see below). I try
pm.beginTransaction;
while(thereAreMoreSchedules){
schedule.set(startDate);
schedule.set(endDate);
activity.setTimestamp(...)
activity.setPersonId(personId); //1:N reference from person to
activity
schedule.set(activity); //1:N reference from schedule to activity
pm.store(schedule);
}
pm.commitTransaction;
pm.close();
On the first time and insert is done succesfully. When I try an update, only
the field timestamp is being updated, personId not. I can't believe, OJB
cannot handle this. Why is it not working
Dirk
-Ursprüngliche Nachricht-
Von: Dirk Manske (Service Respond)
[mailto:[EMAIL PROTECTED]
Gesendet: Montag, 9. Februar 2004 02:12
An: 'OJB Users List'
Betreff: foreign key is not being updated...
Vertraulichkeit: Persönlich
Hi,
I am using the PB-API and struggle with update fk references in the db.
There are three tables Person --> Activity --> Schedule.
Person has a 1:N assoc to Activity. Activity has a 1:N assoc to Schedule.
While you plan the schedule you have to select a person which will be
assigned to the selected activity. For the first time, doing an insert works
well. If you want to change the person, an update fails. There is no error
message though, everything seems fine. I tested it by setting some values
and did an update to the db. All values had been updated, except the fk for
personid in table Activity. Here are the facts:
Activity holds a fk for table Person. Schedule holds a fk for table
Activity. The repository excerpt is as follows:
...
...
...
...
The pk's are primitive integers. I just store the collection
'allAssignedSchedules' in a while loop with broker.store(scheduleObject).
Again, this works well for all attributes except the fk of personId in table
Activity. I do not why. Does someone have an idea?
thx,
Dirk
-
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]
RE: Transaction Problem.
Hi, Armin wrote: > No, problem is when object was only pushed to cache it's not possible to > query the object and you run into the same problem as before.Thanks. If I under stand correctly then using query by Identity with the Broker Api will first query the cache, so if the object was cached I could retrieve it. is there some way I could use it? Thanks Again for the reponses, -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 5:08 PM To: OJB Users List Subject: Re: Transaction Problem. Hi, Ziv Yankowitz wrote: > Hi, > > Thanks for the response. > > if I understand correctly the flush writes the object to the db and cache. yep! > Is there a way to write only to the cache and not to the db and then when commit > accurse the db will be hit. No, problem is when object was only pushed to cache it's not possible to query the object and you run into the same problem as before. regards, Armin > > Thanks. > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 4:59 PM > To: OJB Users List > Subject: Re: Transaction Problem. > > > Hi, > > Ziv Yankowitz wrote: > >>Folks, >> >>I'm using ODMG API . >> >>I'm trying to insert an object and query the object in the same transaction before >>the object was committed is this possible. > > > You have to use a proprietary extension method of Transaction: > ((TransactionExt) tx).flush() > > regards, > Armin > > >>thanks. >> >>- >>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]
RE: Transaction Problem.
No. You have to follow the steps that Armin explained. > -Original Message- > From: Ziv Yankowitz [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 4:05 PM > To: OJB Users List; [EMAIL PROTECTED] > Subject: RE: Transaction Problem. > > > Hi, > > Thanks for the response. > > if I understand correctly the flush writes the object to the > db and cache. > Is there a way to write only to the cache and not to the db > and then when commit accurse the db will be hit. > > Thanks. > > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Monday, February 09, 2004 4:59 PM > To: OJB Users List > Subject: Re: Transaction Problem. > > > Hi, > > Ziv Yankowitz wrote: > > Folks, > > > > I'm using ODMG API . > > > > I'm trying to insert an object and query the object in the > same transaction before the object was committed is this possible. > > You have to use a proprietary extension method of Transaction: > ((TransactionExt) tx).flush() > > regards, > Armin > > > > > thanks. > > > > > - > > 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]
Re: Transaction Problem.
Hi, Ziv Yankowitz wrote: Hi, Thanks for the response. if I understand correctly the flush writes the object to the db and cache. yep! Is there a way to write only to the cache and not to the db and then when commit accurse the db will be hit. No, problem is when object was only pushed to cache it's not possible to query the object and you run into the same problem as before. regards, Armin Thanks. -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 4:59 PM To: OJB Users List Subject: Re: Transaction Problem. Hi, Ziv Yankowitz wrote: Folks, I'm using ODMG API . I'm trying to insert an object and query the object in the same transaction before the object was committed is this possible. You have to use a proprietary extension method of Transaction: ((TransactionExt) tx).flush() regards, Armin thanks. - 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]
RE: Transaction Problem.
Hi, Thanks for the response. if I understand correctly the flush writes the object to the db and cache. Is there a way to write only to the cache and not to the db and then when commit accurse the db will be hit. Thanks. -Original Message- From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, February 09, 2004 4:59 PM To: OJB Users List Subject: Re: Transaction Problem. Hi, Ziv Yankowitz wrote: > Folks, > > I'm using ODMG API . > > I'm trying to insert an object and query the object in the same transaction before > the object was committed is this possible. You have to use a proprietary extension method of Transaction: ((TransactionExt) tx).flush() regards, Armin > > thanks. > > - > 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: Transaction Problem.
Hi, Ziv Yankowitz wrote: Folks, I'm using ODMG API . I'm trying to insert an object and query the object in the same transaction before the object was committed is this possible. You have to use a proprietary extension method of Transaction: ((TransactionExt) tx).flush() regards, Armin thanks. - 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]
Transaction Problem.
Folks, I'm using ODMG API . I'm trying to insert an object and query the object in the same transaction before the object was committed is this possible. thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: foreign key is not being updated...
Hi Dirk,
It looks like you are setting the FK and not the reference object. Therefore, on an
update, OJB is resolving and updating the FK of the set reference object (null!). If
you want to continue setting the FK, you must call pb.resolveReference("reference");
to set the object prior to the store call.
Hope this helps,
Wally
-Original Message-
From: Dirk Manske (Service Respond) [mailto:[EMAIL PROTECTED]
Sent: Monday, February 09, 2004 5:38 AM
To: 'OJB Users List'
Subject: AW: foreign key is not being updated...
Sensitivity: Personal
I am still struggling to update a foreign key (see below). I try
pm.beginTransaction;
while(thereAreMoreSchedules){
schedule.set(startDate);
schedule.set(endDate);
activity.setTimestamp(...)
activity.setPersonId(personId); //1:N reference from person to activity
schedule.set(activity); //1:N reference from schedule to activity
pm.store(schedule);
}
pm.commitTransaction;
pm.close();
On the first time and insert is done succesfully. When I try an update, only the field
timestamp is being updated, personId not. I can't believe, OJB cannot handle this. Why
is it not working
Dirk
-Ursprüngliche Nachricht-
Von: Dirk Manske (Service Respond) [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 9. Februar 2004 02:12
An: 'OJB Users List'
Betreff: foreign key is not being updated...
Vertraulichkeit: Persönlich
Hi,
I am using the PB-API and struggle with update fk references in the db.
There are three tables Person --> Activity --> Schedule.
Person has a 1:N assoc to Activity. Activity has a 1:N assoc to Schedule.
While you plan the schedule you have to select a person which will be assigned to the
selected activity. For the first time, doing an insert works well. If you want to
change the person, an update fails. There is no error message though, everything seems
fine. I tested it by setting some values and did an update to the db. All values had
been updated, except the fk for personid in table Activity. Here are the facts:
Activity holds a fk for table Person. Schedule holds a fk for table Activity. The
repository excerpt is as follows:
...
...
...
...
The pk's are primitive integers. I just store the collection 'allAssignedSchedules' in
a while loop with broker.store(scheduleObject). Again, this works well for all
attributes except the fk of personId in table Activity. I do not why. Does someone
have an idea?
thx,
Dirk
-
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: Help, I'm stuck and I can't get out! (Infinite Loop)
Exists some circustantes that results in infinite loop due to use of EmptyCache with two way navigable references. Are you using this? If yes, try to set a in the recerenced bean with a very low time-out (let's say, 1 sec). It solved almost vast majority of my cases. Best regards, Edson Richter - Original Message - From: Clay Mitchell To: OJB Users List Sent: Saturday, February 07, 2004 2:16 PM Subject: Help, I'm stuck and I can't get out! (Infinite Loop) I seem to have gotten myself stuck in a infinite loop here... Any idea what it's doing and why? Thanks -Clay [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.ProductType, Query from class com.exigentic.onyx.ProductType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Product, Query from class com.exigentic.onyx.Product where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.SpecType, Query from class com.exigentic.onyx.SpecType where [id IN [79, 28, 112]]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.core.QueryReferenceBroker] DEBUG: getCollectionByQuery (class org.apache.ojb.broker.util.collections.RemovalAwareCollection, class com.exigentic.onyx.Specification, Query from class com.exigentic.onyx.Specification where [specId = 28]) [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false ## Here's my repository: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.577 / Virus Database: 366 - Release Date: 3/2/2004
AW: foreign key is not being updated...
I am still struggling to update a foreign key (see below). I try
pm.beginTransaction;
while(thereAreMoreSchedules){
schedule.set(startDate);
schedule.set(endDate);
activity.setTimestamp(...)
activity.setPersonId(personId); //1:N reference from person to
activity
schedule.set(activity); //1:N reference from schedule to activity
pm.store(schedule);
}
pm.commitTransaction;
pm.close();
On the first time and insert is done succesfully. When I try an update, only
the field timestamp is being updated, personId not. I can't believe, OJB
cannot handle this. Why is it not working
Dirk
-Ursprüngliche Nachricht-
Von: Dirk Manske (Service Respond)
[mailto:[EMAIL PROTECTED]
Gesendet: Montag, 9. Februar 2004 02:12
An: 'OJB Users List'
Betreff: foreign key is not being updated...
Vertraulichkeit: Persönlich
Hi,
I am using the PB-API and struggle with update fk references in the db.
There are three tables Person --> Activity --> Schedule.
Person has a 1:N assoc to Activity. Activity has a 1:N assoc to Schedule.
While you plan the schedule you have to select a person which will be
assigned to the selected activity. For the first time, doing an insert works
well. If you want to change the person, an update fails. There is no error
message though, everything seems fine. I tested it by setting some values
and did an update to the db.
All values had been updated, except the
fk for personid in table Activity. Here are the facts:
Activity holds a fk for table Person. Schedule holds a fk for table
Activity. The repository excerpt is as follows:
...
...
...
...
The pk's are primitive integers. I just store the collection
'allAssignedSchedules' in a while loop with broker.store(scheduleObject).
Again, this works well for all attributes except the fk of personId in table
Activity. I do not why. Does someone have an idea?
thx,
Dirk
-
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]
Object Cache question.
Folks, We have a ClassDiscriptor with object cache configured. we are using ODMG API to insert an object. Can we force ODMG to cache the object before commit and then in case of Rollback to call remove. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: GroupBy clause ignored in PersistentBroker.getCount( Query query)
Hi Jakob,
yup I tried to 'patch' the getCount() method and also saw that setting
the copy-groupBy flag to true wouldn't solve the problem.
copying the 'group by' information may be done by iterating on the
results of the Query.getGroubBy() and adding the columns to the report
query.
however, this doesn't return me what i really expected (on sybase) since
it returns me several rows containing the count of the elements
available in the 'groups' and not the total number of grouped results.
Actually the number i would expect may be extracted counting the rows in
the count-query resultset.
However i don't know if every db does the count the same manner as
sybase, so this may not be a viable solution.
actually for 'real' databases (also not sybase) it is possible to use a
ditinct clause for doing exactly what i need, however scheissbase <=
12.0 knows only VARCHAR with a max length of 255, so for longer texts a
data type TEXT (a CLOB) must be used. of course no distinct query can be
done if a table contains TEXT fields.
the horrible trick to simulate a distinct query in sybase is this (for
anyone interested in it):
in case the platform contains the string 'sybase' then instead of
setting the distinct flag, add a group by clause for the PK.
(this is supported by sybase, but will fail on oracle)
drawback is that a count query on this fake distinct query will return
wrong results. and here comes the second horrible trick.
since ojb ignores the group by clause and a OJB distinct count query
adds the distinct clause only on PK columns (that should never be of
type TEXT) then it is possible to safely set the 'distinct' flag for the
count query also for sybase.
so for doing a 'results count limited distinct query' i do the following
(for sybase):
- set the distinct flag on query
- do count query
- if count > than maximum results throw exception
- else reset the distinct flag
- add group by for the PK
- do the query
brr, horrible but works
so, sorry for the long text, but maybe sombody else has the same problem
and that's the (horrible) way i solved it.
if somebody has a better solution i would be glad to hear it, thanks
anyway
cheers
danilo
hi danilo,
the groupBy information is defined in the query not in the criteria, so
the copy() does not make much sense. but there's a problem when counting
reportqueries using groupBy:
Criteria crit = new Criteria();
ReportQueryByCriteria q =
QueryFactory.newReportQuery(ProductGroup.class, crit);
q.setColumns(new String[] { "groupName",
"sum(allArticlesInGroup.stock)", "sum(allArticlesInGroup.price)" });
q.addGroupBy("groupName");
broker.getReportQueryIteratorByQuery(q);
while (iter.hasNext())
{
results.add(iter.next());
}
int count = broker.getCount(q);
assertEquals(results.size(), count); <<< FAILS
results in this sql:
SELECT A0.KategorieName,sum(A1.Lagerbestand),sum(A1.Einzelpreis)
FROM Kategorien A0
LEFT OUTER JOIN BOOKS A1 ON A0.Kategorie_Nr=A1.Kategorie_Nr
LEFT OUTER JOIN CDS A1E2 ON A0.Kategorie_Nr=A1E2.Kategorie_Nr
LEFT OUTER JOIN Artikel A1E1 ON A0.Kategorie_Nr=A1E1.Kategorie_Nr
GROUP BY A0.KategorieName
ojb generates a wrong count-sql :
SELECT count(*) FROM Kategorien A0
or when including groupBy:
SELECT count(*),A0.KategorieName as ojb_col_1 FROM Kategorien A0 GROUP
BY A0.KategorieName
how should the count look like (without using a subquery) ?
jakob
Danilo Tommasina wrote:
Hi,
Is there a reason why the GroupBy clause is beeing ignored in a query
when doing a PersistenceBorker.getCount( Query query )?
In RC4 release I found this piece of code:
class PersistenceBokerImpl
public int getCount(Query query) throws PersistenceBrokerException
{
(...)
// build a ReportQuery based on query
// orderby needs to be cleared
if (query.getCriteria() != null)
{
reportCrit = query.getCriteria().copy(false, false, false);
}
(...)
}
The line:
reportCrit = query.getCriteria().copy(false, false, false);
copies the Criteria ignoring the GroupBy clause, thus causing the
count query to return a wrong number of elements.
Is there a reason for this or has it been fixed after RC4?
thx
bye Danilo
-
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]
--
Danilo Tommasina, Dipl. Ing. FH Telecom
Software Engineer
RCS Riskmanagement Concepts Systems AG
Technoparkstrasse 1
CH-8005 Zuerich
T: +41 1 445 29 08
[EMAIL PROTECTED]
www.risksys.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Object Reference Descriptor.
Hi, Ziv Yankowitz wrote: Folks I am trying to configure an Object Reference Descriptor dynamically can someone please point me to a sample. AFAIK there is no example in docs, but have a look into ...broker.metadata.RepositoryXml#startElement method (line 511). Here you can see how we map metadata of ORD. regards, Armin thanks. - 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: Using Ojb in Applications with large DB tables
Hi, > -Original Message- > From: Var George [mailto:[EMAIL PROTECTED] > Sent: Friday, February 06, 2004 8:35 PM > To: [EMAIL PROTECTED] > Subject: Using Ojb in Applications with large DB tables > > > Is this a bug in OJB (count() vs last.getrow())? I can't verify this at the moment... > Also are any known scalability issues in using OBJ against large > tables (say million+ rows)? No, there are no OJB specific problems in working with large tables. Of course you should take care to provide database indexes for all your table accesses. So Using OJB PB, OTM and ODMG APIs will be fine. But using the OJB JDO binding with large tables is currently a no go. SUN's JDORI does not provide any mechanism for index based selection, but relies on a full table scan mechanism. As OJB simply works as a Plugin to the JDORI we can't change this behaviour! This problem will only be cured when we have our own JDO implementation working! cheers, Thomas > > -- > regards > Var George > > > --- > Hi, > > This is a repost. Could anybody help me on that? > > Thanks, > Zhe > > > > > > > -Original Message- > > From: ZZZ Liu [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, February 03, 2004 3:46 PM > > To: [EMAIL PROTECTED] > > Subject: Re: FW: setStartAtIndex/setEndAtIndex for a > > very large result > > set > > > > > > After more investigation by looking into OJB code, I > > found that the out of memory problem occurs in > > org.apache.ojb.broker.accesslayer.RsIterator.size() > > method. In that method, there are two ways to get > > size: > > 1) count > > 2) .last .getRow > > > > I found that 2) will give me out of memory error.I > > tried that with pure JDBC and also got out of memory > > error. However, if I force to use 1), it works fine. > > I > > am using Oracle 9i. I am worndering whether there is > > any way to solve this problem. Currently I have to > > set > > jdbc-level="1.0" instead of "2.0" to force 1) is > > used. > > > > Thanks, > > Zhe > > > > > > > > > > -Original Message- > > > From: ZZZ Liu [mailto:[EMAIL PROTECTED] > > > Sent: Monday, February 02, 2004 9:01 PM > > > To: [EMAIL PROTECTED] > > > Subject: setStartAtIndex/setEndAtIndex for a very > > > large result set > > > > > > > > > Hi, All > > > > > > I am trying to do a simple query against a very > > > large > > > table with over 200,000 records. I use > > > QueryByCriteria > > > without any criteria, but settiing > > > setStartAtIndex(1) > > > and setEndAtIndex(2). Then I use > > getIteratorByQuery > > > to > > > get the result. However, I got OutOfMemory error. > > > > > > I tried the same thing on a relatively small table > > > (about 100 records) and it works fine. > > > > > > Could anybody shed some light on this? > > > > > > Thanks, > > > Zhe > > > - > 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]
