On 8/6/01 11:57 AM, "Fedor Karpelevitch" <[EMAIL PROTECTED]>
wrote:
> I'd like to ignite a little discussion on the future of Peer system. Here
> are some ideas which have beed brewing in my mind lately. Some depend on
> each other, some are mutually exclusive:
>
> - New Query Model (whatever that is). It's a long overdue..
I'm just catching up on email. But I would like to see the next version of
torque be based on the work of Scott Ambler and eventually move towrard a
JDO implementation. The query model should have nothing to do with SQL, the
query should be constructed in terms of the objects used in the application.
The application should not be coupled to the database schema, application
programmers should not be affected by changes in the underlying database
schema.
I have the code from player.sourceforge.net and some another Scott Ambler
implenentation that was donated to the ASF and I am merging them all into a
single implementation to try out. I think it is the best design to follow,
many people are familiar with Scott Ambler and design has been tested in the
field.
I will post some more notes about it later. I will be pushing for the next
version of torque to be based on the paper of Scott Ambler.
> - Stateful Peers. In many cases the all-static Peers are just fine and very
> convenient. However in quite a few cases stateful (instance) Peers would be
> of great help. Probably the most common case is per-usersession Peers which
> would keep link back to session info which would allow them to automatically
> apply some filters ( such as only selecting current user's info or info for
> the date of interest) instead of having this code duplicated all over the
> application code. As both stateful and stateless Peers have their area of
> application it seems that it makes sense to make this a generation option.
>
> - Move Peer's functionality into OM objects themselves. It makes fewer
> classes and removes some duplication and seems to be overall more elegant. I
> do not see any good arguement against this although I am not really sure
> about this one. just a thought...
>
> - better typing & exceptions. For example I would prefer doSelect to return
> List rather than Vector. And for example a method doSelectDistinct
> (doSelectUnique?) returning a Set and so forth. Also methods like one
> returning Hashtable with PKs as keys and full objects as values would often
> be handy... As to exceptions having all methods throw Exception is highly
> annoying. A good exception hierarchy would be great.
>
> what do you think?
>
> fedor.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
