Bugzilla – Full Text Bug Listing
| Summary: | Provide mechanisms to allow pluggable LOB management at repository level | ||
|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Erdal Karaca <erdal.karaca.de> |
| Component: | cdo.core | Assignee: | Project Inbox <emf.cdo-inbox> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | alex.lagarde, chewbizz, jerome.benois, mariot.chauvin, stepper, steve.monnier |
| Version: | 4.13 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
Guys, what about a DelegatingStore that implements InternalStore by delegating to any kind of "real" store? This delegating store should be able to customize any piece of functionality. (In reply to comment #1) > Guys, what about a DelegatingStore that implements InternalStore by delegating > to any kind of "real" store? This delegating store should be able to customize > any piece of functionality. Sounds too complex, doesn't it? Or: How/where would I plug in the "LOB management"? Maybe, I missed something... You'd intercept the following methods: IStoreAccessor.queryLobs(List<byte[]>) IStoreAccessor.loadLob(byte[], OutputStream) IStoreAccessor.handleLobs(long, long, CDOLobHandler) IStoreAccessor.write(InternalCommitContext, OMMonitor) IStoreAccessor.commit(OMMonitor) IStoreAccessor.rollback() I agree with the newsgroup discussion in that the proper participation in the transaction when committing LOBs will probably be the most challenging task. But that's unrelated to the place where the LOB handling is hooked up. Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. Moving all outstanding enhancements to 4.3 Moving all open enhancement requests to 4.4 Moving all open enhancement requests to 4.4 Moving all open bugzillas to 4.5. Moving all unaddressed bugzillas to 4.6. Moving all open bugs to 4.7 Moving all unresolved issues to version 4.8- Moving all unresolved issues to version 4.9 Moving to 4.13. |
Currently, all lob management is handled by the underlying store of the repository. It would be great if this could be possible independently of the store. I.e. at repository level. Maybe, to be configured like this: <repository> <lobAccessor class="com.example.MyJCRLobAccessor"> <!-- NOTE: implementation specific properties --> <property name="webDavAccessPoint" value="http://localhost:8080/repository/default/" /> <property name="user" value="admin" /> <property name="pwd" value="admin" /> </lobAccessor> <store...>...</store> </repository> Then, org.eclipse.emf.cdo.internal.server.Repository.handleLobs(long, long, CDOLobHandler) could be rewritten to: public void loadLob(byte[] id, OutputStream out) throws IOException { if ( lobAccessor == null ) { IStoreAccessor accessor = StoreThreadLocal.getAccessor(); accessor.loadLob(id, out); } else { lobAccessor.loadLob(id, out); } } The other two methods could be changed accordingly... Such an enhancement would allow CDO users to re-use existing content management systems, e.g. they would be able to use a JCR implementation as their lob storage...