Re: using a second database

2006-04-18 Thread Helge Weissig

On Apr 17, 2006, at 12:36 PM, Thomas Vandahl wrote:

Yes, you can still do that. The name in the schema and the name in  
the Torque configuration have nothing to do with the real name of  
the database. This is usually specified in the JDBC-URL only. The  
other two names are just used to handle the matching of generated  
objects and configurations appropriately.


I for example do this as well: The name of my schema is turbine  
and the name of my developer database is testdb.


ok, so now I am confused! I played around with different settings and  
I thought I had it down: The db name in the schema.xml file is  
inserted into the create-db.sql script and into all generated  
BasePeer objects and the configuration name in the Torque.properties  
file needs to be the same as well. Hence, if we want folks to work in  
their own sandbox, we would have to have


database name=sandbox1.../database
torque.database.default=sandbox1
torque.dsfactory.sandbox1.factory=org.apache.torque.dsfactory.PerUserPoo 
lDataSourceFactory

torque.dsfactory.sandbox1. ...

I can see how you can work around that by enforcing manual creation  
of the db though. Maybe the lesser of the two not-so-evils?


cheers,
h.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: using a second database

2006-04-18 Thread Helge Weissig
As I said below, you and Thomas are correct except for the creation  
of the database. If you want torque to create it, the name in the  
schema.xml file needs to be the same as the one specified in your  
connection URL.


cheers,
h.


On Apr 18, 2006, at 11:54 AM, Guy Galil wrote:


All you need to do is change the url string in your torque.properties
file - each developer should have the url point to a different  
database:

as long as in your schema your database name is db
for developer 1
torque.dsfactory.db.connection.url
=jdbc:mysql://someip:someport/sandbox1

for developer 2
torque.dsfactory.db.connection.url
=jdbc:mysql://someip:someport/sandbox2

The database name in the schema and the objects is just a logical
pointer to the settings in the properties file.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Torque and iBATIS

2006-04-18 Thread Greg Monroe
I took a quick look at Hibernate a while back and came away with the 
impression that it is strongly tied to the complexity of Enterprise
Java Beans.  It simplifies EJB operations but still requires a lot of
manual bookkeeping and coding to get started.

So, IMHO, Torque was better because it lets you go from laying 
out the tables to using code much faster.  Torque's tools also help
support and speed up a lot of the processes needed to go from
development to delivery and then maintaining the application. Things
like:

Having an easily produced common file that describes and documents
your application's data storage schema. (Makes version comparison
a simple matter of comparing XML file versions.)

It makes the generation of the SQL scripts to create the DB schema
for your application a snap, regardless of which vendor you are using.

Ease of implimenting changes to tables into your code.  Just change
the xml schema and rebuild.

Ease (but not enforcement) of creating cross DB Server engine code,
so you're application is not tied to a single vendor's implimentation.

Others with more hibernate experience might have different opions. But
I'd say if you don't need EJB support, don't use Hibernate.

And FWIW, IMHO, after working with a major EJB application for 5+ years
and then developing it's replacement with Torque, EJB is overkill for most 
common applications which really don't need 100%, never loose a 
transaction due to acts of god.  A good clustered Servlet only environment 
can give you 99.9+% reliablility without all of EJB's overhead (which is 
a real response killer with all it's open sockets between this and that..)

Oh, and as to performance, one thing that Torque does well is to 
supply a nice easy to configure/use connection caching methodogy.
This is a big performance gain for any OM layer since a large part
of SQL transaction overhead is simply establishing the connections
to the DB.  You should look at what other OM layers do in this 
regard if you are concerned about response time performance.


 -Original Message-
 From: Tomáš Procházka [mailto:[EMAIL PROTECTED] 
 
  I have again small question.
 
  Why you prefer Torque before Hibernate?
 


Duke CE Privacy Statement
Please be advised that this e-mail and any files transmitted with it are 
confidential communication or may otherwise be privileged or confidential and 
are intended solely for the individual or entity to whom they are addressed.  
If you are not the intended recipient you may not rely on the contents of this 
email or any attachments, and we ask that you  please not read, copy or 
retransmit this communication, but reply to the sender and destroy the email, 
its contents, and all copies thereof immediately.  Any unauthorized 
dissemination, distribution or copying of this communication is strictly 
prohibited.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]