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 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]
>>
>>
>
> --
> [image: @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
>
>
>
>
--
[image: @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
------------------------------------------------------------------------------
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
