ResultSetAdapter

[Greg Brown <gk...@mac.com>]

I'm going to suggest that we abandon the ResultSetAdapter concept. There's not enough "meat" to justify including it in the platform. By the time I was done stubbing it out last night, the class was mostly done. My conclusion is that this can an be more efficiently done at the application level. It gives more control to the app developer and eliminates the need to make modifications to JSONSerializer and CSVSerializer to accommodate it.

Unless there are objections, I'm going to remove this class from SVN.

Re: ResultSetAdapter

[Sandro Martini <sa...@gmail.com>]

Ok, for me no problem, remove it.

Bye

Re: ResultSetAdapter

[Greg Brown <gk...@mac.com>]

>I think there is a fair amount of scope for making the lives of CRUD
>database application programmers easier.

>But those are much bigger pieces to implement.

Right - and they have already been tackled by numerous server-side frameworks. So, we don't really need to play there.

Re: ResultSetAdapter

[Noel Grandin <no...@gmail.com>]

I think there is a fair amount of scope for making the lives of CRUD
database application programmers easier.

But you'll need to think higher-level components.

E.g. a DataTable that can read from various persistence APIs (JDBC,
Hibernate, JDO, JPA, and probably some kind of RESTful JSON web service)
and configure columns automatically.
and
default auto-configuring CRUD interfaces ala Rails

But those are much bigger pieces to implement.

Greg Brown wrote:
> I'm going to suggest that we abandon the ResultSetAdapter concept. There's not enough "meat" to justify including it in the platform. By the time I was done stubbing it out last night, the class was mostly done. My conclusion is that this can an be more efficiently done at the application level. It gives more control to the app developer and eliminates the need to make modifications to JSONSerializer and CSVSerializer to accommodate it.
>
> Unless there are objections, I'm going to remove this class from SVN.
>
>
>