On Thu, 4 May 2006, Greg Monroe wrote:
-----Original Message-----
From: Thomas Fischer [mailto:[EMAIL PROTECTED]
On Fri, 28 Apr 2006, Greg Monroe wrote:
1) So far, Torque has been supporting accessing several
databases at the same time. Your code above only cares for
the default db, not for others that might be around.
I think there is some confusion here... I'm talking about
org.apache.torque.map.DatabaseMap that is used as the "root"
object for each schema Map stored in the Database object
instances that TorqueInstance maintains for each DB name.
The getDatabaseMap methods return the DatabaseMap instance
object for the associate DB schema name. So this code
should be multi DB safe.
In addition, Henning's code to generated the initialization
classes and my code from properties files all have the DB
name embedded in their names. E.g, The "bookstore" schema
will generate BookstoreMapInit.java and
torque-bookstore-map-init.properties, while the "test"
schema will generate TestMapInit.Java... and so on. These
allow for multiple DB schema's with only the same "schema
names must be unique" restriction that Torque currently has.
My excuses. I did not look thoroughly enough at your code, I could
have seen that myself without bothering you.
2) Make sure everything you do is also working if you have
several schema files for the same database as well as several
schema files for different databases around (the last case is
linked to comment 1)
Not a problem, I've actually finally set up a Torque Maven test
bed here (hence the spat of MSSQL related Test issues in JIRA).
I'll include a test case for this in my code submission.
You can also use the test project for the first part. There are several
schema files around, all of which belong to the database "bookstore" (at
least after the copying and filtering).
3) When this was discussed last year, some people cared about
startup time, which could be long for large schema files. Make
sure one can still use the old way to initialize the database
Map. Probably the best way to do this would be to add a
configuration property.
Actually, my thinking on this is that no changes will need to
be made to the init processess at all. If your application
logic needs a fully populated Map, then the app code should
call the initialize() method. It only populates the map once,
so it's not a performance hit to call it multiple times.
If you need to initialize everything, just init Torque, then
use getDatabases() to work from there. Once again, an
application specific but generic method of doing this.
That is fine. If someone calls the MapBuilder's initialize() method, he
should know what he is doing.
4) Make sure that the runtime still works without any
generated classes being around.
That's a sub-reason for the above thoughts. The only place
it fails is if the application specifically calls the
initialize() code. And this code wraps all the possible
errors due to parts in TorqueExceptions with specific
messages.
If you don't care about ensuring all map info is populated
in your code, you don't get effected. Life works exactly
the same, with lazy map population as needed.
If you do care, since you are messing about with reflection
type of coding, your code should add application specific
safe guards. Just like you should when using the Java
reflection methods.
FYI, I will add a ToDo to beef up the JavaDocs in this area
and this is another good test case to add.
...
Why should the database map care about how the database is
accessed (i.e. the peer classes) and the database objects ?
It is just a map of the structure of the database and has no
need to access teh database in any way.
It's basically the same issue/reason that JDBC drivers support
access to SQL Meta data. A high percent of applications don't
need this. But sometimes, if it's available, an application
can really use it. (Like Torque's jcbc to schema Task...)
If you are starting from a generic set of information (e.g.
XML parsed set of strings), you need to figure out how to map
this into the OM layer objects and decisions made if this
information is to be Inserted or Updated.
I'm not going to make a religious war out of this :-). If the Peers would
have instance methods, I would agree that a getPeer() method in the
Database map which would return a Peer instance would make sense. But as
long as the peer methods are static, I'd rather not introduce this, unles
you can convince me that one can write sensible code with the
DatabaseMap.getPeer() method which one could not have written without.
...
I'm not advocating this... but if we wanted to be really full
featured, the map structures should contain enough information
for the schema XML to be recreated from it. 8) That's just
a thought for the future.
I agree that all of the information in the schema.xml should be in the
database map in the end.
As far as I understand it, ListOrderedMap is equivalent to
LinkedHashMap. However, ListOrderedMap works with java 1.3,
whereas LinkedHashMap does not. So far the runtime has been
java 1.3 compatible, so please use ListOrderedMap.
[ Writes under his breath with big 8) on face]
Grumble grumble... code done..grumble..have to rewrite..
grumble.. supporting dinosaurs... grumble...grumble
[ big sigh ]
Come on :-) I should be just one import statement and one assign
statement (where the map is created). All other stuff should stay the
same, assuming that the variable type is Map and not SomeSpecialMap.
OK, I'll use that. Just out of curiosity do we know if all
the dependent jar's are 1.3 complient as well? Just because
Torque's code compiles under 1.3 doesn't mean the support
code is OK with it at runtime.
I did not check that, but I'd be surprised if it were otherwise. Torque
only depends on quite basic stuff, which usually is way backwards
compatible. I'm not sure about avalon, but the Torque runtime can be used
without the avalon library if avalon is not used.
As far as I know, all of the "modern" map implementations need to be
wrapped in a synchronizedMap to be synchronized.
Yes, and any iteration objects retrieve from then need to be
synchronized on the Collection object as well.. (is now..and
[grumble] rewrite will be to)
If you have to do this, the implementation was already buggy before you
changed the type of the map. Map iterations need to be synchronized for
every type of synchronized map.
Hey, never mind the rewriting, thats what I do all the time. I implement
things, and then, being finished and starting to write the email to the
dev list, I discover that it could have done better, and start
rewriting the code...
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
