You are viewing a plain text version of this content. The canonical link for it is here.
Posted to torque-user@db.apache.org by "Michael Moossen NO TENGO! ." <mm...@123mail.cl> on 2004/08/23 11:51:39 UTC
my experience with torque
Hi, all
first of all, i want to give my solution for counting the number of rows with a Criteria, a question i saw no remember where, may be in the wiki?
take a not null column (may be a pk column), add the condition:
row is not null
and add a select column
count(*)
it works, but i think it will be slower than a count without the condition, depending of the db engine.
now, after spending several days of works integrating my app with torque, i am really disappointed with the restrictions of torque... i mean, it is normal that any app has restrictions, but they should be well documented.
in torque's docs i have not seen any word speaking about the restriction to single column pk tables.
the criteria how-to just speaks about a limitation for outer joins.. but it can not handle conditions splits through several columns, like:
id is not null or (date1 < today and date2 > today)
another suggestions to the developers:
- id_broker seems to be a nice tool but it is restricted to single column pks... think about a Invoice with pk (year, month, nr) where the nr has to be autoincremented but restarted each month, my solution is prior to insert to select max(id) where year=.. and month=.. and increment it, which can be generalised.
Criteria has to be improved:
- why to use two criterias for updates, just add this funcionallity to Criteria by some set(column, value) methods and that is.
- i think a criteria intention should be declared explicitly, via an abtract factory and/or a enum like:
CriteriaFactory.getNewSelectCriteria()
or
new Criteria(Criteria.SELECT)
- i am a fan of prepared statements (normal statements need formatting and escaping, it is simplier and more secure to encapsulate a java.util.Date into a java.sql.TimeStamp than to format it, where you have to take care of the db engine date format), torque uses PS, but i have seen a case where not, don't remember where...
- when you support more general pks, it should be nice when Criteria allows to specify a join (over several fields), and other things, just given a PrimaryKey object (which should refer to several columns, of course)
- now i am fixing some essential things providing facades for Criteria and BasePeer and Query, but it was not easy sence SqlEnum is package private...
- i hope next releases fix some limitations, but it seems to be hard, because they affect the core design... but at least guys, put this in the documentation as visible as posible...
- i think it is also a good idea to keep the project up to date with java versions, to use log4j has no sence since java 1.4 includes the logging API. and to include a jar for just use one or two methods of StringUtils, is not worth...
finally, thanx for all the effort for doing torque possible and stay working on it.... i am still using most torque's capabilities and more important i got tons of good ideas from it..
best regards,
michael
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
Re: my experience with torque
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
Paco Nathan <pa...@symbiot.com> writes:
>One thing to keep in mind about log4j is that it's more mature and yet
>progressing faster than Sun's logging package in Java. For example,
>java.util.logging in JDK 1.4 hasn't reached anywhere close to the level
>of support provided by log4j Adapters. If an application has real
>needs for notification/remediation/trouble-ticketing, that can become a
>sore spot for system integration. Many other projects use log4j, so if
>you integrate use of Torque along with other systems, it pays to keep a
>common ground for logging. More about that at:
>http://wiki.apache.org/logging-log4j/Log4jvsJDKLogging
>To add to Scott's note about JDK support ... I'm working on an open
>source project which has JDK 1.4 as a dependency, and we've found this
>exact point to be one of our biggest hurdles for cross-platform
>adoption. For example, FreeBSD is just barely offering a stable
>alternative for a 1.4 compiler.
We use commons-logging and try to be log-engine agnostic. You can
use any log engine that is supported by commons-logging.
Please don't quote Cekis paper again. Personally I disagree with it.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
Re: my experience with torque
Posted by Paco Nathan <pa...@symbiot.com>.
Hola Michael,
Interesting discussion, good points.
One thing to keep in mind about log4j is that it's more mature and yet
progressing faster than Sun's logging package in Java. For example,
java.util.logging in JDK 1.4 hasn't reached anywhere close to the level
of support provided by log4j Adapters. If an application has real
needs for notification/remediation/trouble-ticketing, that can become a
sore spot for system integration. Many other projects use log4j, so if
you integrate use of Torque along with other systems, it pays to keep a
common ground for logging. More about that at:
http://wiki.apache.org/logging-log4j/Log4jvsJDKLogging
To add to Scott's note about JDK support ... I'm working on an open
source project which has JDK 1.4 as a dependency, and we've found this
exact point to be one of our biggest hurdles for cross-platform
adoption. For example, FreeBSD is just barely offering a stable
alternative for a 1.4 compiler.
Paco
On 23 Aug 2004, at 06:06, Scott Eade wrote:
> Michael Moossen NO TENGO! . wrote:
>>
>> - i think it is also a good idea to keep the project up to date with
>> java versions, to use log4j has no sence since java 1.4 includes the
>> logging API. and to include a jar for just use one or two methods of
>> StringUtils, is not worth...
>>
> Most ASF projects strive to support jdk 1.3 and forward as often in
> corporate environments people are stuck with these older versions. By
> using commons logging you can take advantage of jdk 1.4 logging if you
> so desire. As for StringUtils, there are a tonne of useful things in
> Commons Lang - Torque may use just a few methods, but your application
> can benefit from using these classes too.
>
>> finally, thanx for all the effort for doing torque possible and stay
>> working on it.... i am still using most torque's capabilities and
>> more important i got tons of good ideas from it..
>>
>> best regards, michael
>>
>
> Welcome to Torque.
>
> Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
Re: my experience with torque
Posted by Scott Eade <se...@backstagetech.com.au>.
Michael Moossen NO TENGO! . wrote:
>Hi, all
> first of all, i want to give my solution for counting the number of rows with a Criteria, a question i saw no remember where, may be in the wiki?
> take a not null column (may be a pk column), add the condition:
> row is not null
>and add a select column
> count(*)
>it works, but i think it will be slower than a count without the condition, depending of the db engine.
>
>
Yes, I do something like:
criteria.addSelectColumn("count(" + TurbineUserPeer.USER_ID + ")");
Have you added this to the wiki?
>
> now, after spending several days of works integrating my app with torque, i am really disappointed with the restrictions of torque... i mean, it is normal that any app has restrictions, but they should be well documented.
> in torque's docs i have not seen any word speaking about the restriction to single column pk tables.
>
>
As Andras said, you can indeed have multi-column primary keys - how well
this is integrated with IDBroker I do not know.
> the criteria how-to just speaks about a limitation for outer joins.. but it can not handle conditions splits through several columns, like:
> id is not null or (date1 < today and date2 > today)
>
>
Criteria.Criterion (again see message from Andras).
>
> another suggestions to the developers:
> - id_broker seems to be a nice tool but it is restricted to single column pks... think about a Invoice with pk (year, month, nr) where the nr has to be autoincremented but restarted each month, my solution is prior to insert to select max(id) where year=.. and month=.. and increment it, which can be generalised.
>
>
There is an enhancement in the TORQUE_3_1_HENNING branch of cvs that I
think provides a Torque om class for accessing the IDBroker table - this
may help with what you are trying to do. I know Henning would like some
feedback on the utility of his enhancements with a view to bringing them
back into the trunk. I personally tend to use keys independent from my
data and so there is not often the need to construct multi-part keys.
> Criteria has to be improved:
>- why to use two criterias for updates, just add this funcionallity to Criteria by some set(column, value) methods and that is.
>- i think a criteria intention should be declared explicitly, via an abtract factory and/or a enum like:
> CriteriaFactory.getNewSelectCriteria()
>or
>new Criteria(Criteria.SELECT)
>
>
I'd have to give some more thought the these, they would be quite
fundamental changes to a design that was forged some time ago.
>- i am a fan of prepared statements (normal statements need formatting and escaping, it is simplier and more secure to encapsulate a java.util.Date into a java.sql.TimeStamp than to format it, where you have to take care of the db engine date format), torque uses PS, but i have seen a case where not, don't remember where...
>
>
I think PS support requires some work in Torque. I know that Thomas
Fischer (who is working on extending the join support) has noted a few
discrepancies with PS - a small quote:
> I am
> not sure why BasePeer.createQuery(..) processes the groupBy- and
> Having-Lists of Criteria while BasePeer.createPreparedStatement(..)
> doesn't, but I left it as it was, though I think it's a bit fishy. Also,
> the criteria.getLimit() and criteria.getOffset() are processed
> differently
> by BasePeer.createQuery(..) and BasePeer.createPreparedStatement(..). I
> could see no reason for this
>- when you support more general pks, it should be nice when Criteria allows to specify a join (over several fields), and other things, just given a PrimaryKey object (which should refer to several columns, of course)
>
>- now i am fixing some essential things providing facades for Criteria and BasePeer and Query, but it was not easy sence SqlEnum is package private...
>
We may well make SqlEnum public in the next release as it is most likely
necessary to support and take advantage of the additional join types.
You are welcome to contribute to the future of Torque - subscribe to
torque-dev and post some patches.
>
>
>- i hope next releases fix some limitations, but it seems to be hard, because they affect the core design... but at least guys, put this in the documentation as visible as posible...
>
>- i think it is also a good idea to keep the project up to date with java versions, to use log4j has no sence since java 1.4 includes the logging API. and to include a jar for just use one or two methods of StringUtils, is not worth...
>
>
Most ASF projects strive to support jdk 1.3 and forward as often in
corporate environments people are stuck with these older versions. By
using commons logging you can take advantage of jdk 1.4 logging if you
so desire. As for StringUtils, there are a tonne of useful things in
Commons Lang - Torque may use just a few methods, but your application
can benefit from using these classes too.
>finally, thanx for all the effort for doing torque possible and stay working on it.... i am still using most torque's capabilities and more important i got tons of good ideas from it..
>
>best regards,
>michael
>
>
Welcome to Torque.
Scott
--
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
Re: my experience with torque
Posted by Andras Balogh <an...@reea.net>.
Hello,
Michael Moossen NO TENGO! . wrote:
>Hi, all
> first of all, i want to give my solution for counting the number of rows with a Criteria, a question i saw no remember where, may be in the wiki?
> take a not null column (may be a pk column), add the condition:
> row is not null
>and add a select column
> count(*)
>it works, but i think it will be slower than a count without the condition, depending of the db engine.
>
> now, after spending several days of works integrating my app with torque, i am really disappointed with the restrictions of torque... i mean, it is normal that any app has restrictions, but they should be well documented.
> in torque's docs i have not seen any word speaking about the restriction to single column pk tables.
>
>
I don't think torque is limited to single column primary key, you can
define more columns as primary keys but you need to specify idMethod none
since only you know how to generate these primay key values (most
probably they are foreign keys to another table)
> the criteria how-to just speaks about a limitation for outer joins.. but it can not handle conditions splits through several columns, like:
> id is not null or (date1 < today and date2 > today)
>
>
Are you sure? Have you seen Criteria.Criterion??
(http://db.apache.org/torque/criteria-howto.html)
>
> another suggestions to the developers:
> - id_broker seems to be a nice tool but it is restricted to single column pks... think about a Invoice with pk (year, month, nr) where the nr has to be autoincremented but restarted each month, my solution is prior to insert to select max(id) where year=.. and month=.. and increment it, which can be generalised.
> Criteria has to be improved:
>- why to use two criterias for updates, just add this funcionallity to Criteria by some set(column, value) methods and that is.
>- i think a criteria intention should be declared explicitly, via an abtract factory and/or a enum like:
> CriteriaFactory.getNewSelectCriteria()
>or
>new Criteria(Criteria.SELECT)
>
>- i am a fan of prepared statements (normal statements need formatting and escaping, it is simplier and more secure to encapsulate a java.util.Date into a java.sql.TimeStamp than to format it, where you have to take care of the db engine date format), torque uses PS, but i have seen a case where not, don't remember where...
>
>- when you support more general pks, it should be nice when Criteria allows to specify a join (over several fields), and other things, just given a PrimaryKey object (which should refer to several columns, of course)
>
>- now i am fixing some essential things providing facades for Criteria and BasePeer and Query, but it was not easy sence SqlEnum is package private...
>
>- i hope next releases fix some limitations, but it seems to be hard, because they affect the core design... but at least guys, put this in the documentation as visible as posible...
>
>- i think it is also a good idea to keep the project up to date with java versions, to use log4j has no sence since java 1.4 includes the logging API. and to include a jar for just use one or two methods of StringUtils, is not worth...
>
>finally, thanx for all the effort for doing torque possible and stay working on it.... i am still using most torque's capabilities and more important i got tons of good ideas from it..
>
>best regards,
>michael
>
>
>
>
Best regards,
Andras.
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
Re: my experience with torque
Posted by "Henning P. Schmiedehausen" <hp...@intermeta.de>.
"Michael Moossen NO TENGO! ." <mm...@123mail.cl> writes:
> - id_broker seems to be a nice tool but it is restricted to single column pks... think about a Invoice with pk (year, month, nr) where the nr has to be autoincremented but restarted each month, my solution is prior to insert to select max(id) where year=.. and month=.. and increment it, which can be generalised.
If you write code like this, you are already doomed. You should look
at the papers published by Scott Ambler at www.agiledata.org
One of the key rules is: "Never assign meaning to primary
keys". Torque follows these rules and yes, we don't support ID
generation as you describe.
If this is legacy data: Tough. You can always write your own ID
generator und plug it into your schema.
If this is a newly designed DB: Redesign. Your design is bad.
> Criteria has to be improved:
>- why to use two criterias for updates, just add this funcionallity to Criteria by some set(column, value) methods and that is.
>- i think a criteria intention should be declared explicitly, via an abtract factory and/or a enum like:
> CriteriaFactory.getNewSelectCriteria()
Go ahead and present us with patches. This is, what open source software is all about. :-)
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
hps@intermeta.de +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
"Fighting for one's political stand is an honorable action, but re-
fusing to acknowledge that there might be weaknesses in one's
position - in order to identify them so that they can be remedied -
is a large enough problem with the Open Source movement that it
deserves to be on this list of the top five problems."
-- Michelle Levesque, "Fundamental Issues with
Open Source Software Development"
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org
AW: my experience with torque
Posted by Ferruh Zamangoer <fe...@gistec-online.de>.
Hi NG,
michael has wrote the following:
In torque's docs i have not seen any word speaking about the restriction
to single column pk tables.
Does it mean that I can not have single column pk tables or have I
understand it wrong???. Are there any other way to solve this Problem ?
Regards
Ferruh
---------------------------------------------------------------------
To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
For additional commands, e-mail: torque-user-help@db.apache.org