You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Max Rudman <mr...@steelbrick.com> on 2004/12/18 01:07:20 UTC
Commons Mapper: scope/roadmap?
I've just discovered Commons Mapper project and would like to
contribute. I built my own abstraction layer for Hibernate but would
love to move to Mapper instead. I looked through current documentation
and have a couple of questions.
1) Are specific implementations within the scope of this project? You
mention several data mapping technologies (such as Hibernate, iBATIS,
etc.) in project overview but I saw no specific implementations in the
JavaDocs API. As I said, I have experience with Hibernate and would
like to contribute in providing Hibernate Mapper implementation (if
this is something that needs to be done).
2) Is query API something you envision being part of this package?
Specifically, a Query-By-Example API which I found to be very useful in
enterprise application development where one often needs to have the
ability to search for records with flexible (dynamic) WHERE clause.
Hibernate package provides such an API but obviously it is specific to
their implementation and it would be nice to have the abstraction layer
against that functionality as well.
This is my first time inquiring about contributing to Jakarta Commons
so I apologize in advance if I am doing something inappropriate. I did
search through both user and dev mailing list archives but couldn't
find any information on the topics above.
Thanks in advance,
Max
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Mapper: scope/roadmap?
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
Max Rudman wrote:
>
>> Specifically, I'm not exactly planning on a Query-by-Example API, but
>> rather a dynamic SQL statement builder API (also insert, update,
>> delete, etc.). I run into this problem all the time where the user is
>> specifying what they'd like to search for, and so you need to build a
>> SQL statement on-the-fly.
>
>
> Yes, dynamic SQL/OQL generation is exactly what I am talking about.
> Perhaps I chose Query-By-Example terminology poorly in that it's not QBE
> itself but rather the API that enables QBE-type functionality.
>
>
>> If you're curious, take a look at the DynamicSqlSelectStatment interface.
>
>
> I looked at your code (DynamicSqlSelectStatement) and it looks very much
> like something I had built (I call it QueryBuilder). Do you plan support
> for functions, GROUP BY and ORDER BY clauses? You might have that in the
> rest of your API as I didn't look thoroughly.
Actually the original version I did for my old firm for v1.0 was called
QueryBuilder. Then when I was exposed to HQL I renamed it
SqlQueryBuilder and introduced an HqlQueryBuilder. We're definitely
thinking along the same lines :) I've never implemented a GROUP BY
clause before, but I certainly think it's valuable.
>> Let me know if you have any comments, questions, etc!
>
>
> So, are you planning a persistence (O/R mapping) layer like Apache
> ObjectBridge and Hibernate or an abstraction API like Mapper?
Actually, I'm planning on using Morph (morph.sourceforge.net) to provide
the functionality that Mapper does. I was planning on having this wait
until Morph 1.1, but so you can see what I'm talking about I'll try to
get it out the door this weekend. The nice thing with using Morph will
be if you have a ResultSet like this
StartDate (String), EndDate (String), MyNumber (Number)
that needs to be mapped to an object with properties
Date getStartDate();
Date getEndDate();
int myNumber();
You will be able to do it all declaratively with an IoC framework,
including the type conversions!
> Max
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Mapper: scope/roadmap?
Posted by Max Rudman <mr...@steelbrick.com>.
> Specifically, I'm not exactly planning on a Query-by-Example API, but
> rather a dynamic SQL statement builder API (also insert, update,
> delete, etc.). I run into this problem all the time where the user is
> specifying what they'd like to search for, and so you need to build a
> SQL statement on-the-fly.
Yes, dynamic SQL/OQL generation is exactly what I am talking about.
Perhaps I chose Query-By-Example terminology poorly in that it's not
QBE itself but rather the API that enables QBE-type functionality.
> If you're curious, take a look at the DynamicSqlSelectStatment
> interface.
I looked at your code (DynamicSqlSelectStatement) and it looks very
much like something I had built (I call it QueryBuilder). Do you plan
support for functions, GROUP BY and ORDER BY clauses? You might have
that in the rest of your API as I didn't look thoroughly.
> Let me know if you have any comments, questions, etc!
So, are you planning a persistence (O/R mapping) layer like Apache
ObjectBridge and Hibernate or an abstraction API like Mapper?
Max
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Mapper: scope/roadmap?
Posted by Matt Sgarlata <sg...@users.sourceforge.net>.
I never noticed Mapper before... interesting. Actually I will be
tackling some of the same problems once I get Morph out the door
(morph.sourceforge.net). It will be a separate project focused on DB
interaction but I haven't thought of a name yet (I'm calling it
"Persistence" for now, but that's too generic).
Specifically, I'm not exactly planning on a Query-by-Example API, but
rather a dynamic SQL statement builder API (also insert, update, delete,
etc.). I run into this problem all the time where the user is
specifying what they'd like to search for, and so you need to build a
SQL statement on-the-fly. I think we can do better than straight String
concatenation :) I already wrote something similar at my old firm (it
supported both SQL and HQL) that worked great in production systems, but
it is not open source. So I'm starting again, this time open source,
and whatever I come up with will be almost like a version 2.0 once its
version 1.0 comes out.
You can download the source I've written so far from here:
http://www.crystalcognition.com/sgarlatm/persistence.zip
If you're curious, take a look at the DynamicSqlSelectStatment interface.
Let me know if you have any comments, questions, etc!
Matt
Max Rudman wrote:
> I've just discovered Commons Mapper project and would like to
> contribute. I built my own abstraction layer for Hibernate but would
> love to move to Mapper instead. I looked through current documentation
> and have a couple of questions.
>
> 1) Are specific implementations within the scope of this project? You
> mention several data mapping technologies (such as Hibernate, iBATIS,
> etc.) in project overview but I saw no specific implementations in the
> JavaDocs API. As I said, I have experience with Hibernate and would like
> to contribute in providing Hibernate Mapper implementation (if this is
> something that needs to be done).
>
> 2) Is query API something you envision being part of this package?
> Specifically, a Query-By-Example API which I found to be very useful in
> enterprise application development where one often needs to have the
> ability to search for records with flexible (dynamic) WHERE clause.
> Hibernate package provides such an API but obviously it is specific to
> their implementation and it would be nice to have the abstraction layer
> against that functionality as well.
>
> This is my first time inquiring about contributing to Jakarta Commons so
> I apologize in advance if I am doing something inappropriate. I did
> search through both user and dev mailing list archives but couldn't find
> any information on the topics above.
>
> Thanks in advance,
>
> Max
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Mapper: scope/roadmap?
Posted by David Graham <gr...@yahoo.com>.
--- Max Rudman <mr...@steelbrick.com> wrote:
>
> On Dec 17, 2004, at 8:52 PM, David Graham wrote:
>
> > There aren't any reusable implementations that I can think of. What
> do
> > you picture the Hibernate mapper implementation looking like?
> Well, I am not too familiar with other O/R implementations but at least
> in Hibernate you don't need a separate Data Access Object (DAO)
> implementation for each value object. Everything needed to persist and
> load Person is captured in Person.hbm.xml mapping file.
>
> What I have in mind for Hibernate implementation is HibernateMapper
> class which will hold on to Hibernate Session object and Class of the
> entity being persisted. HibernateMapperFactory then would simply pass
> through entity class to the Mapper so it can in turn use it in its
> calls to Hibernate Session. It would look something like this:
>
> public class HibernateMapper implements Mapper {
> private net.sf.hibernate.Session session;
> private Class type;
>
> public HibernateMapper(Session session, Class type) {
> this.session = session;
> this.type = type;
> }
>
> public Object findByUniqueId(Object id) {
> return session.get(type, id);
> }
>
> .....
>
> }
>
> This is probably very oversimplified and there is a fair amount of
> "housekeeping" code; hence, the value of providing an implementation as
> part of the Mapper project instead of forcing users to re-invent the
> wheel so to speak.
>
> In addition, we could provide an implementation which works with Spring
> Framework, for example, which is an IoC container I am very fond of.
> That way, the whole MapperFactory configuration can be done out of XML
> config files and provided to business logic classes in the "Injection
> of Dependency" manner. As a bonus, Spring integrates with Hibernate to
> provide automatic transaction management and such.
>
> I imagine something similar can be done for other O/R frameworks; I am
> just not familiar enough with them to give you more details.
>
> > Mapper really saved me on one project where we designed a new db
> schema
> > and wrote a bunch of code to access it and then mgmt. decided to use
> > the
> > old schema at the last minute. All I had to do was implement the
> > mappers
> > differently and the rest of the app. never changed.
>
> I agree, O/R tools are great but being able to switch to a different DB
> schema is a virtue of the O/R mapping tool itself not the abstraction
> API like Mapper. In other words, it seems to me I could have achieved
> the same result by using Hibernate directly as opposed to hard-coding
> DB schema in JDBC calls.
In my particular example certain tables did not exist in the old schema so
I had to simulate them with XML files. The mapper implementation read
from XML instead of the database. Hibernate is a wonderful tool but it
needs database tables :-).
> If I understood the project's goal correctly,
> it is to abstract various O/R implementations in a manner similar to
> how Commons Logging abstracts various Logging implementations.
The idea behind Mapper is insulating the application from the details of
data retrieval including SQL, HQL, etc. The app. just calls
PersonMapper.findByFirstName() and the implementation uses SQL, HQL, or
queries XML as needed. The implementation may not be using a relational
database at all.
David
>
> Max
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Mapper: scope/roadmap?
Posted by Max Rudman <mr...@steelbrick.com>.
On Dec 17, 2004, at 8:52 PM, David Graham wrote:
> There aren't any reusable implementations that I can think of. What do
> you picture the Hibernate mapper implementation looking like?
Well, I am not too familiar with other O/R implementations but at least
in Hibernate you don't need a separate Data Access Object (DAO)
implementation for each value object. Everything needed to persist and
load Person is captured in Person.hbm.xml mapping file.
What I have in mind for Hibernate implementation is HibernateMapper
class which will hold on to Hibernate Session object and Class of the
entity being persisted. HibernateMapperFactory then would simply pass
through entity class to the Mapper so it can in turn use it in its
calls to Hibernate Session. It would look something like this:
public class HibernateMapper implements Mapper {
private net.sf.hibernate.Session session;
private Class type;
public HibernateMapper(Session session, Class type) {
this.session = session;
this.type = type;
}
public Object findByUniqueId(Object id) {
return session.get(type, id);
}
.....
}
This is probably very oversimplified and there is a fair amount of
"housekeeping" code; hence, the value of providing an implementation as
part of the Mapper project instead of forcing users to re-invent the
wheel so to speak.
In addition, we could provide an implementation which works with Spring
Framework, for example, which is an IoC container I am very fond of.
That way, the whole MapperFactory configuration can be done out of XML
config files and provided to business logic classes in the "Injection
of Dependency" manner. As a bonus, Spring integrates with Hibernate to
provide automatic transaction management and such.
I imagine something similar can be done for other O/R frameworks; I am
just not familiar enough with them to give you more details.
> Mapper really saved me on one project where we designed a new db schema
> and wrote a bunch of code to access it and then mgmt. decided to use
> the
> old schema at the last minute. All I had to do was implement the
> mappers
> differently and the rest of the app. never changed.
I agree, O/R tools are great but being able to switch to a different DB
schema is a virtue of the O/R mapping tool itself not the abstraction
API like Mapper. In other words, it seems to me I could have achieved
the same result by using Hibernate directly as opposed to hard-coding
DB schema in JDBC calls. If I understood the project's goal correctly,
it is to abstract various O/R implementations in a manner similar to
how Commons Logging abstracts various Logging implementations.
Max
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons Mapper: scope/roadmap?
Posted by David Graham <gr...@yahoo.com>.
There aren't any reusable implementations that I can think of. What do
you picture the Hibernate mapper implementation looking like?
The idea is that your app talks to the Mapper API which is implemented as
sql, hibernate, etc. However, each implementation will be very specific
to your app. For example you might have a SqlPersonMapper that knows how
to work with your Person db table using JDBC and then switch to using an
HqlPersonMapper without the app. knowing because it uses the Mapper
interface (or an extended PersonMapper sub-interface).
Mapper really saved me on one project where we designed a new db schema
and wrote a bunch of code to access it and then mgmt. decided to use the
old schema at the last minute. All I had to do was implement the mappers
differently and the rest of the app. never changed.
David
--- Max Rudman <mr...@steelbrick.com> wrote:
> I've just discovered Commons Mapper project and would like to
> contribute. I built my own abstraction layer for Hibernate but would
> love to move to Mapper instead. I looked through current documentation
> and have a couple of questions.
>
> 1) Are specific implementations within the scope of this project? You
> mention several data mapping technologies (such as Hibernate, iBATIS,
> etc.) in project overview but I saw no specific implementations in the
> JavaDocs API. As I said, I have experience with Hibernate and would
> like to contribute in providing Hibernate Mapper implementation (if
> this is something that needs to be done).
>
> 2) Is query API something you envision being part of this package?
> Specifically, a Query-By-Example API which I found to be very useful in
> enterprise application development where one often needs to have the
> ability to search for records with flexible (dynamic) WHERE clause.
> Hibernate package provides such an API but obviously it is specific to
> their implementation and it would be nice to have the abstraction layer
> against that functionality as well.
>
> This is my first time inquiring about contributing to Jakarta Commons
> so I apologize in advance if I am doing something inappropriate. I did
> search through both user and dev mailing list archives but couldn't
> find any information on the topics above.
>
> Thanks in advance,
>
> Max
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
__________________________________
Do you Yahoo!?
Send a seasonal email greeting and help others. Do good.
http://celebrity.mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org