Home » Modeling » EMF » CDO Custom store type
| | | |
| Re: CDO Custom store type [message #754446 is a reply to message #754424] |
Wed, 02 November 2011 14:50   |
 Shumy Mising name
Messages: 24
Registered: March 2010
Location: Aveiro, Portugal |
Junior Member |
|
|
Ok, I'll explain what my intention is with this service. Maybe there are diferent solutions...
I want something that I call "data uniformization service". A service that will shield, data sources and implementations from the client. For the client is all about 3 main services: EMF + CRUD + Query.
For the server: is about translation of client requests to any other kind of data provider with distributed transaction resolution. For example, I'm able to mix RDBMS + File System + DICOM + ... in a way that provides a kind of Virtual File System to the client. Remember that the client only has knowledge of EMF + CRUD + Query, with these it will be able to search for DICOM or other files, indexed by a RDBMS, load and upload these files.
Another advantage is that, I have now 2 development teams => one with implementation domain knowledge, and other for client UI.
When I use JPA, I'm able to do these with listeners PrePersist, PreUpdate, etc.
I don't know if this is possible with CDO, the documentation is scarse on that!
|
|
|
| Re: CDO Custom store type [message #754487 is a reply to message #754446] |
Wed, 02 November 2011 17:40 |
Erdal Karaca
Messages: 854
Registered: July 2009 |
Senior Member |
|
|
Shumy wrote on Wed, 02 November 2011 10:50Ok, I'll explain what my intention is with this service. Maybe there are diferent solutions...
I want something that I call "data uniformization service". A service that will shield, data sources and implementations from the client. For the client is all about 3 main services: EMF + CRUD + Query.
For the server: is about translation of client requests to any other kind of data provider with distributed transaction resolution. For example, I'm able to mix RDBMS + File System + DICOM + ... in a way that provides a kind of Virtual File System to the client. Remember that the client only has knowledge of EMF + CRUD + Query, with these it will be able to search for DICOM or other files, indexed by a RDBMS, load and upload these files.
Another advantage is that, I have now 2 development teams => one with implementation domain knowledge, and other for client UI.
When I use JPA, I'm able to do these with listeners PrePersist, PreUpdate, etc.
I don't know if this is possible with CDO, the documentation is scarse on that!
What a coincidence 
I recently ended implementing such a feature: Query any data source on the server side to use CDO to transport the result to the client.
E.g.: I needed to query User data (name, phone, mail, etc.) from a LDAP server. This was done on the server side and the results went back to the client to be joined to another data set (just user ids)...
I used a custom query handler which I registered on the server side and use this to query the "foreign query":
q = transaction.createQuery("myCustomQueryHandler", "named.query.on.server");
q.setParameter("userId", "MYSAMACCOUNTNAME");
Just have a look at how the sql and/or ocl query handlers are implemented...
|
|
|
| Re: CDO Custom store type [message #754504 is a reply to message #754487] |
Wed, 02 November 2011 19:27 |
Shumy Mising name
Messages: 24
Registered: March 2010
Location: Aveiro, Portugal |
Junior Member |
|
|
Erdal Karaca:
Yes, but it doesn't feel like the same!
Has I understand you are merging in the client, different sources of data. I don't want that, I just want the correct model (EMF) and data in the client. If you change LDAP to other data provider you need to config your client for this new adapter, and for all your clients (althought Update Manager can help here).
What the "Uniformization Data Service" is supose to do, is just avoid that.
In the case of the Virtual File System, is a bit more complex than simple ID merge, and I don't want that kind of merge responsabilities on the client.
I think I will bypass CDO and build my own CRUD + Query API. It was something I was trying to avoid, but Store and StoreAccessor overrides seems to complex without proper documentation.
Maybe I will use ECF, thanks for that info
|
|
|
Goto Forum:
Current Time: Fri Apr 26 00:42:11 GMT 2024
Powered by FUDForum. Page generated in 0.03535 seconds |
] 
Search
Help
Register
Login
Home
