| Extending the SDO API [message #390341] |
Tue, 04 January 2005 14:09  |
|
Originally posted by: rpiazza.us.ibm.com
Has anyone considered doing this? What I have in mind concerns mostly Type
and Property. I would like to have special Types and Properties that have
different behavior when I persist them.
Does it make sense to extend classes like ETypeImpl?
Any comments would be appreciated....
Rich Piazza
IBM Rational
|
|
|
|
| Re: Extending the SDO API [message #390344 is a reply to message #390342] |
Tue, 04 January 2005 15:36  |
|
Originally posted by: rpiazza.us.ibm.com
> I understand "Types and Properties that have different behavior when I
> persist them" as you want to define your own persistence mechanism and
> not use the default persistence mechanism for your Types and Properties.
Actually, no. I will be using the EJB Mediator to do the actual
persistence, but I want to add services.
For instance, if I have a data object that keeps a history of changes, I
would like to persist the history in the database also. Assuming that you
specify this in the model when you define the Type, a developer wouldn't
have to do any extra programming to get this behavior for their data
objects.
|
|
|
| Re: Extending the SDO API [message #390346 is a reply to message #390344] |
Tue, 04 January 2005 17:18 |
 Bertrand Portier
Messages: 11
Registered: July 2009 |
Junior Member |
|
|
Rich Piazza wrote:
>>I understand "Types and Properties that have different behavior when I
>>persist them" as you want to define your own persistence mechanism and
>>not use the default persistence mechanism for your Types and Properties.
>
>
> Actually, no. I will be using the EJB Mediator to do the actual
> persistence, but I want to add services.
> For instance, if I have a data object that keeps a history of changes, I
> would like to persist the history in the database also. Assuming that you
> specify this in the model when you define the Type, a developer wouldn't
> have to do any extra programming to get this behavior for their data
> objects.
>
>
In that case, I think you should look at the EMF Adapter (and
AdapterFactory) API. Adapters receive notifications of object changes,
and can extend the behavior of those objects.
If you create adapters for your Types (EClass), each time a Propety
(attribute, reference) of DataObjects (EObject) instances of this Type
is set, the adapter will receive change notification. Note that you can
keep track of changes at the instance level (instead of just at the
"type" of object level).
Bertrand
|
|
|
| Re: Extending the SDO API [message #390348 is a reply to message #390346] |
Tue, 04 January 2005 17:29 |
|
Originally posted by: rpiazza.us.ibm.com
> In that case, I think you should look at the EMF Adapter (and
> AdapterFactory) API. Adapters receive notifications of object changes,
> and can extend the behavior of those objects.
I looked into the adapter mechansim, which isn't exactly what I want, and
anyway, the history
example that I gave is just one of the "services" I would like to add.
There are others, and they don't
necessarily have to do with persistence or change, per se.
Essentially, I want to extend the metadata, which is why I want to extend
Type and Property....
By the way, thanks for your replies!
|
|
|
|
| Re: Extending the SDO API [message #390360 is a reply to message #390350] |
Wed, 05 January 2005 11:20 |
|
Originally posted by: rpiazza.us.ibm.com
This looks promising....any documentation on it??
"Dave Steinberg" <davidms@ca.ibm.com> wrote in message
news:crfr8v$hnv$1@www.eclipse.org...
> Rich Piazza wrote:
> > Essentially, I want to extend the metadata, which is why I want to
extend
> > Type and Property....
>
> Hi Rich,
>
> Might it make sense to extend the metadata using annotations, similar to
> how we did with ExtendedMetaData?
>
> (The subtle message here would seem to be that extending Ecore is not
> usually recommended.) ;)
>
> Cheers,
> Dave
|
|
|
| Re: Extending the SDO API [message #390369 is a reply to message #390360] |
Wed, 05 January 2005 14:54 |
Dave Steinberg
Messages: 488
Registered: July 2009 |
Senior Member |
|
|
Rich Piazza wrote:
> This looks promising....any documentation on it??
Sadly, no. There isn't even any Javadoc in the ExtendedMetaData
interface yet. I've been busily writing, and will check that in soon
(hopefully within the next 24 hours). I'm also working on documenting
it for the second edition of the book, but I'm sure you don't want to
another 8 months for that. ;)
Basically, the idea is to create a convenient interface for storing
additional state as EAnnotations on Ecore model elements. We found that
there was a lot of information that could be specified in XML Schema but
not directly represented in Ecore. So, we chose this approach, rather
than extending Ecore.
EAnnotations are very flexible: you can store key-value string pairs in
the details map, as well as contain and reference arbitrary EMF objects.
ExtendedMetaData represents everything as a detail entry.
Cheers,
Dave
|
|
|
Powered by
FUDForum. Page generated in 0.01918 seconds
] 
Search
Help
Register
Login
Home
