Aruna A. Raghavan<br />SCJP, SCJD, SCWCD
Well you can think about more databases later, but the assignment doesn't suggest that that is necessary or will occur in the future. So by assuming that there is only one Data class and not multiple, then you will make the assignment easier, without adding extra that won't get you extra points.
My instructions explicitly stated that the database would be re-used in future projects. They also encourage coding the user interface with an eye on future enhancements -- which may well require another database table. It's not exactly an outlandish requirement, a second database table. Finally, the very fact that Data is a completely generic class that is not FBN-specific in any way should hammer the point home in case it wasn't clear yet.Originally posted by Mark Spritzler:
Well you can think about more databases later, but the assignemtn doesn't suggest that that is necessary or will occur in the future.
I beg to differ. The supplied Data class does not make this assumption anywhere and is no more complicated for it. Restricting your design to a single table brings questionable simplifications at best. In fact, most efforts to cripple the database server by introducing Singletons make the design more complicated, not less.So by assuming that there is only one Data class and not multiple, then you will make the assignment easier, without adding extra that won't get you extra points.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Aruna A. Raghavan<br />SCJP, SCJD, SCWCD
Aruna A. Raghavan<br />SCJP, SCJD, SCWCD
Aruna A. Raghavan<br />SCJP, SCJD, SCWCD
Aruna A. Raghavan<br />SCJP, SCJD, SCWCD
Originally posted by Eugene Kononov:
I respectfully disagree with Mark on this issue.
[ December 27, 2002: Message edited by: Eugene Kononov ]
Eugene, you often disagree with Mark on many issues
Another project may instantiate a dozen ConnectionFactory objects; the design allows it, or rather, is not deliberately crippled to prevent you from doing this. Did it complicate the design? No. Did it aid reusability? You bet. That's a no-brainer to me, but YMMV.
the right to bear arms
Actually -- but don't tell anyone -- I submitted something close to your second option, a connection factory with a connect(String tableName) method. It doesn't matter though. Either way, I would not want to make the ConnectionFactory a Singleton. When you parameterize the connect() method to take a table name, a ConnectionFactory would correspond roughly to a database schema, and making it a Singleton would mean removing the ability to have more than one schema for no good reason at all.Originally posted by HS Thomas:
You seem to suggest to allow instantiating one ConnectionFactory object per Business Object / Table - the reuse being in the objects that are created subsequently rather than 1 ConnctionFactory being reused for all BO/Tables.
Am I right in thinking this?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Let me rephrase. There are broadly two approaches you can take with your ConnectionFactory (or whatever you call it)Originally posted by HS Thomas:
I'm still trying to absorb this . So the first option would allow more than one database schema in a single JVM or many JVMs?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Do the simplest thing. In this case that probably means you get a connection (i.e. a DataInterface implementation, either a local Data or a remote Connection) as soon as your application starts and release it only when the application quits.Originally posted by HS Thomas:
1. Using instances of ConnectionFactory connect(tableName1) and ConnectionFactory connect (tableName2) within a given schema at which point do I " connect" them ?
Probably not. Unless you do implement bizarre limitations in your code, the user of your networked database libary will be able to bind any number of ConnectionFactory objects in the RMI registry and created truly complicated databases living on multiple JVMs and multiple machines. But the Fly By Night Massively Parallel Database Cluster is probably out of scope for the assignment2. I was going to ask about schema's in other JVM's but that's not relevant anymore, I think.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Not only is the the Fly By Night Massively Parallel Database Cluster is out of scope, I would submit that the Fly By Night Relational Database Management System is outside assignment scope as well, in the sense that the galactic core is outside the solar systemOriginally posted by HS Thomas:
[...] is there an Object equivalent of a SQL table join?
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |