Hi Mark (and anyone else that may be interested),
I've posted an alternative DAO demo implementation at
https://github.com/robintaylor/DSpace/tree/DS-1172 that only requires
one Spring config file and keeps everything within dspace-api. Its a bit
messy as I've hardcoded a package name into the code...
String classname = "org.dspace.content.dao." + capitalisedDbname +
"CollectionDAO";
I would be grateful for any criticism. The problem I generally run up
against is that there is no method...
DSpace().getSingletonService(String id);
...that would wrap the Spring method...
getBean(String id)
Cheers, Robin.
On 11/05/12 16:34, Mark Diggory wrote:
Robin can you post a link to the two classes you have referenced
below, I want to really understand what the significant differences
are that require completely different code.
Even in your example, the the oracle vs Postgres DAO can exist in the
spring config together and be lazy loaded. If you want to have the
runtime code select between them in the manner your showing, put them
in a set or a map and pick them out of that inside a parent DAO
"container".
I say this because in JPA, an EntityManager is responsible for
marshalling/unmarshalling the object from the rdbms, so it
encapsulates the differences between the vendors not at the level of
your model classes, but lower down in the JPA implementation itself.
And in Spring JDBCTemplates the SQL differences are externalized into
the templates.
The providers are then for separate persistence frameworks (Hibernate,
Spring Templates, JDO, JPA) not specifically JDBC vendor.
In our case, if we were to use spring JDBC templates, we could
probibly still encapsulate the oracle/Postgres differences in the
template class, but the JDBC driver swapping could still be controlled
in the manner currently defined.
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/jdbc.html
I think it's important to first move the code inside DSpace-API and
manually configure in config/spring, we can come around after showing
the separation functionally works to discuss using addons or not for
selection of the provider.
Mark
On Friday, May 11, 2012, Robin Taylor wrote:
Hi Sands,
My initial plan was just to have the DAOs within dspace-api,
possibly in separate packages, but I was unable to accomplish it
with our Spring based ServiceManager (very probably due to a lack
of understanding on my part). In classic Spring you might have a
configuration of ...
<bean id="postgresCollectionDAO"
class="org.dspace.content.dao.PostgresCollectionDAO" />
<bean id="oracleCollectionDAO"
class="org.dspace.content.dao.OracleCollectionDAO" />
So you would form your id by something like...
String id = dbname + "CollectionDAO"
and use Spring to instantiate the appropriate class for you. But
our ServiceManager doesn't appear to allow that. It seemed to me
that the only thing available to me was...
DSpace.getSingletonService(java.lang.Class<T> type)
Which would have meant having to have Spring config that looked
like...
<bean id="org.dspace.content.dao.CollectionDAO"
class="org.dspace.content.dao.PostgresCollectionDAO" />
<bean id="org.dspace.content.dao.CollectionDAO"
class="org.dspace.content.dao.OracleCollectionDAO" />
But that is not permitted and wouldn't work anyway. To get round
this you need to create separate modules for Oracle and Postgres
each with its own Spring config file, that way you can reuse the
same 'id's in each file, assuming you only include one of the
files in the final build.
At first this seemed an unnecessary hassle to me to have to create
separate modules when my aim was just to get some DAOs in, but I
can see some merit. It would allow someone to come along and give
us a separate module for Mysql, or even just give us a jar, and it
could be plugged in without any need for a committer to apply the
changes to dspace-api. Taking this argument further, suppose we
want to build in support for non-JDBC database access, or even
other forms of storage, would we push everything into dspace-api ?
Or should the storage related code be hived off into its own
module(s) ?
As I say my knowledge of our ServiceManager is rudimentary so I am
happy to be corrected.
Cheers, Robin.
On 11/05/12 04:54, Sands Alden Fish wrote:
Hi Robin,
I see no reason not to move forward with the work in general. (I
am of course just one committer, and could quite possibly be
looking over a concern here.)
As far as creating separate Maven modules though, this *feels*
kind of heavy-handed and complex for the benefit of building
separate DAO packages separately. Is it really worth the
additional complexity, instead of just building all db support
into the final build by default? Happy to hear an argument for
it. This is just my gut reaction.
Cheers,
-Sands
On May 10, 2012, at 9:24 AM, Robin Taylor wrote:
Hi all,
I just wanted to run something by you to check that I am not
misbehaving.
I have in my mind to try and implement some form of DAO's for
3.0, but
its very much a hobby project for me at this stage so I haven't
made too
much noise about it other than seeking guidance from Mark D. As
work
progresses the aim would be to create separate maven modules for
the
DAOs and for the org.dspace.storage.rdbms package on which they
would
depend. The reason for having separate modules for the various DAO
implementation (Oracle, Postgres, etc) would be to make use of the
existing Maven profiles activated by the choice of database in
order
that the Maven build would add the appropriate dependency. As I
write I
realise I need to write this up in more detail on the wiki.
As preparatory work I need to remove dependencies on dspace-api
from
some of the classes in org.dspace.storage.rdbms. Its just
refactoring
work with no new functionality eg. replacing references to
ConfigurationManager with ConfigurationService, so I've just been
raising Jira records for each piece of work with an associated pull
request and leaving them for a week to allow comment (see
DS-1156 and
DS-1160). Assuming there are no objections I've just been
merging the
changes into master (I'm getting the hang of this Git lingo).
If/when I
reach the point of doing something more contentious, such as
moving the
org.dspace.storage.rdbms package into its own module, I would
certainly
be seeking approval from the committers/developers in the normal
fashion. If approval wasn't forthcoming nothing would be lost
since the
refactorings I'm doing at the moment would probably be
considered good
things to do in their own right.
Any objections if I continue in this fashion ?
Thanks, Robin.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond.
Discussions
will include endpoint security, mobile security and the latest
in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-commit mailing list
dspace-com...@lists.sourceforge.net
--
@mire Inc.
*Mark Diggory *(Schedule a Meeting <https://tungle.me/markdiggory>)
/2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
/Esperantolaan 4, Heverlee 3001, Belgium/
http://www.atmire.com <http://www.atmire.com/>
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
