Hi Mark,
Thanks for the guidance, that's a neat solution. I'm just having one wee
problem at the moment. When I try and select the appropriate DAO (point
4 below) I am getting an Exception. If you have a wee minute could you
take a look at
https://github.com/robintaylor/DSpace/commit/6d3dbd24c3e2f3b632d59cf36ec2f71b52864c34#diff-5
, I think the problem occurs when I try and access the
ConfigurationService. If I comment out that line and just use a
hardcoded value of 'postgres' it works fine. Would you expect the
ConfigurationService to be available at that point ? Don't worry if you
don't have time to look at this, I'll investigate myself but I just
thought I would ask in case you knew the answer off the top of your head.
Cheers, Robin.
PS. What I posted to GitHub is very much a work in progress so please
turn a blind eye to the numerous "rough edges" :)
On 23/05/12 06:52, Mark Diggory wrote:
Robin, I've been meaning to spend some time getting back to you on
this topic.
If we were to just use spring and abandon the dspace configuration
approach, we could implement the selection of the appropriate DAO as a
choice between spring xml files placed into dspace/config/spring/...
Since we want to keep both dao around and choose the appropriate one,
we could use the property placeholder config to lookup the appropriate
classname of the bean to wire into the manager or we can load them
both into the manager using autowiring using something like the
following...
1. Create a CollectionService bean that will provide a generic
non-vendor specific interface to interact with your storage (to hold
common CRUD). Use it's classname as the identifier to look it up via
the service manager by static methods in Collection.
2. Add a setDAOProviders(List<CollectionDAO>) method to the above service.
3. In the spring config, use autowire="byType" to set collection the
various CollectionDAO Implementations in the Service.
4. Create an id property with getter on each of the vendor dao that
designates the capitalizedDbname associated with the appropriate
vendor dao. Add some code to (2) to pick the appropriate DAO out of
the set and set it as the selected DAO to be used in the service.
The actual selection will be a few lines of code, and then the dao can
have any package name, com.blaa, org.foo. Do not make the same mistake
as in the curator tools, you only need to implement CollectionDAO and
provide some id in the bean to map to the db.name <http://db.name>
config in the service manager.
Mark
On Friday, May 18, 2012, Robin Taylor wrote:
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
[email protected]
--
@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/>
--
@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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
