You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Fedor Karpelevitch <fe...@Barra.COM> on 2001/08/06 17:57:13 UTC
thoughts on the future of the Peer system
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..
- 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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: thoughts on the future of the Peer system
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Fedor Karpelevitch <fe...@Barra.COM> writes:
> 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..
Yes, save us!
> - 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.
I would very much like to see Peers move from all static methods to an
instanc model. There should also be an easy way to get the same
instance each time for cases where instances aren't actually necessary.
> - 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...
I'm not too sure about this one.
> - 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.
+1 to List over Vector (for the umpteenth time!). I think you've got
some good typing ideas here, Mr. TypeSafe. Let's not go overboard on
the exceptions, though. If you really want to add more, they should
all subclass a common base class so those of us who aren't interested
in specific exception types can easily ignore them when desired.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: thoughts on the future of the Peer system
Posted by Jason van Zyl <jv...@apache.org>.
On 8/6/01 11:57 AM, "Fedor Karpelevitch" <fe...@Barra.COM>
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: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org