Home » Modeling » EMF » [CDO] Model to file on server
| [CDO] Model to file on server [message #430514] |
Mon, 25 May 2009 16:09  |
Eclipse User |
|
|
|
Originally posted by: maurice.gmail.com
Hi,
I'd like to write a new, incoming CDO model to a disk on the server before
it is commited to the database, work some magic on it, then put it into
the DB.
So far, I have setup a WriteAccessHandler, which contains the override:
public void handleTransactionBeforeCommitting(ITransactiontransaction
transaction, CommitContext commitContext, OMMonitor monitor)
However, using these objects I'm finding it difficult to access the model
data to save it to disk.
Does anyone know how this should be done?
I see that EMF stuff can be saved out like so:
http://kathayat.wordpress.com/2007/07/26/saving-the-emf-mode l-to-xml-file/
I gather it's a similar process for CDO?
Maurice
|
|
|
| Re: [CDO] Model to file on server [message #430516 is a reply to message #430514] |
Mon, 25 May 2009 16:17  |
|
Maurice,
No, it's completely different from serializing an EMF model instance to
a file. Recently I explained some details about the access handlers in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=277075#c8
That said, you may not change the information passed into the handler
(if it's possible via public API at all)!his information is cached at
different locations in the network and chaning it here can leave the
network in an unconsistent state.
Cheers
/Eike
----
http://thegordian.blogspot.com
Maurice schrieb:
> Hi,
>
> I'd like to write a new, incoming CDO model to a disk on the server
> before it is commited to the database, work some magic on it, then put
> it into the DB.
>
> So far, I have setup a WriteAccessHandler, which contains the override:
>
> public void handleTransactionBeforeCommitting(ITransactiontransaction
> transaction, CommitContext commitContext, OMMonitor monitor)
>
> However, using these objects I'm finding it difficult to access the
> model data to save it to disk.
> Does anyone know how this should be done?
>
> I see that EMF stuff can be saved out like so:
> http://kathayat.wordpress.com/2007/07/26/saving-the-emf-mode l-to-xml-file/
>
>
> I gather it's a similar process for CDO?
>
> Maurice
>
>
>
>
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Model to file on server [message #430519 is a reply to message #430516] |
Mon, 25 May 2009 17:43 |
| Eclipse User |
|
|
|
Originally posted by: maurice.gmail.com
Hi Eike,
Thanks for your response
> That said, you may not change the information passed into the handler
> (if it's possible via public API at all)!his information is cached at
> different locations in the network and chaning it here can leave the
> network in an unconsistent state.
To give you some context: I am looking to run a transformation on an
incoming regular UML2 Model, to make it CDO compatible. I would like to do
this server-side.
Is there a mechanism inside CDO which would allow for running a
transformation and modifying the incoming data before it is committed to
the CDO server?
If not, could you confirm that we can't change the model data through the
WriteAccessHandler, as this would make a mess of things (even if the
transaction's meta-info was unchanged)?
So if we can't pursue either of these options, I guess we'd have to write
our own proxy to accept the client connection, modify the incoming
transaction and forward it to the CDO server?
Maurice
|
|
|
| Re: [CDO] Model to file on server [message #430525 is a reply to message #430519] |
Tue, 26 May 2009 05:40 |
|
Maurice,
Comments below...
Maurice schrieb:
> Hi Eike,
> Thanks for your response
>
>> That said, you may not change the information passed into the handler
>> (if it's possible via public API at all)!his information is cached at
>> different locations in the network and chaning it here can leave the
>> network in an unconsistent state.
>
> To give you some context: I am looking to run a transformation on an
> incoming regular UML2 Model, to make it CDO compatible. I would like
> to do this server-side.
What do you mean by "incoming"? Are you saying that a regular UML2
instance arrives at the CDO repository because a CDO client has
committed it as part of a transaction? That would surprise me because
we're currently working hard on making this possible ;-)
>
> Is there a mechanism inside CDO which would allow for running a
> transformation and modifying the incoming data before it is committed
> to the CDO server?
There are introspection hooks (i.e. for reading and reacting) at several
levels (client side: CDOTransactionHandler, server side:
Read/WriteAccessHandler) but no, there is no possibility to change what
is being introspected.
I think this could make a good enhancement request but you'd have to
contribute major effort to make this happen anytime soon. Each of the
two introspection hooks has its own subtle complications with respect to
changing the information: At client side you'd have to deal with
CDOSavePoint structures and at server side you'd have to deal with the
problem that the CDO (network) protocol is currently not prepared to
transfer the changed data back to the client that originally sent the
unmodified data so that it can update its caches and data structures.
Anyway, if you're considering to go one of these routes, we can offer
our knowledge to support you. The work must be done by you.
> If not, could you confirm that we can't change the model data through
> the WriteAccessHandler, as this would make a mess of things
Confirmed.
> (even if the transaction's meta-info was unchanged)?
What do you mean by "transaction's meta-info"?
>
> So if we can't pursue either of these options,
What was the second option? It's early in the morning here and I'm still
with my first coffee, so I might be missing something :P
> I guess we'd have to write our own proxy to accept the client
> connection, modify the incoming transaction and forward it to the CDO
> server?
This is completely unclear to me. I better not go into detail on how
complicated and fragile it would be to proxy the CDOServerProtocol
because that would not change anything about the above argument that the
initiating client would be left in an inconsistent (well, at least a
different) state. As I said, if you really consider to add support for
changing data on the way being committed you really have to consider the
complete way of this data from the commiting client to the repository
*and back* .
Cheers
/Eike
----
http://thegordian.blogspot.com
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
Goto Forum:
Current Time: Sat Apr 27 02:50:48 GMT 2024
Powered by FUDForum. Page generated in 0.02904 seconds |
] 
Search
Help
Register
Login
Home
