db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <tfisc...@apache.org>
Subject RE: Plan to enhance Database Mapping info
Date Thu, 04 May 2006 21:06:20 GMT

On Thu, 4 May 2006, Greg Monroe wrote:

>> -----Original Message-----
>> From: Thomas Fischer [mailto:tfischer@apache.org]
>> 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...


To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message