Home » Modeling » EMF » XSDEcoreBuilder --> using a different EcorePackage instance
| |
| Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434049 is a reply to message #433706] |
Thu, 30 July 2009 19:02   |
 Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
I am persisting dynamic (non-generated) epackages, but because these have references to the ecore model also (i.e. to
the XMLTypePackage most of the time), I also need to persist (in the database) the ecore and xmltypepackages themselves.
I don't like that :-( but I need to because for example a persisted estructuralfeature can refer to an edatatype to the
epackage itself (persisted in the database) or to an ecore type.At database level I don't know the difference... This
also applies to epackages which belong to generated classes and 'dynamic' epackages.
But your answer is clear!
One last question, can I detect that an EPackage has a generated EPackage class available somewhere? I mean an EClass
has an instancetypename but an epackage does not seem to have such a thing.
gr. Martin
Ed Merks wrote:
> Martin,
>
> Comments below.
>
>
> Martin Taal wrote:
>> Hi,
>> I am persisting ecore models in the database. Including the
>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>> correctly I also use my own EPackage.Registry which has my own
>> instance of EcorePackage (read from the database).
>>
>> First a general question: is it possible/feasible to have my own
>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean will
>> having my own EPackage.Registry solve all the issues I can have with
>> references to the Ecore types themselves? Or are there hidden things I
>> should be aware of (for example with the way that base edata types are
>> resolved through the extendedmetadata)?
> I don't think that would work well...
>>
>> I noticed at least one location where the EcorePackage/XMLTypePackage
>> are used 'hardcoded' and not through a package registry. That is the
>> XSDEcoreBuilder. I can solve this in two ways:
>> - copy XSDEcoreBuilder and replace all the hard-references to these
>> packages with one resolved through a packageregistry (the
>> XSDEcoreBuilder has a package registry)
>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards and
>> replace all references to the EcorePackage instance (incl. the
>> edatatypes/eclasses it has etc.) with references to my own instances
>> of EcorePackage (the same for XMLTypePackage etc.).
> Changing code seems like a bad plan.
>>
>> What is the best way in your opinion (or maybe both are very unsmart
>> and there is an other great elegant way to solve this)?
> I'm not sure why you'd need to persist models that should be
> ubiquitously available. In general, if you have a generated model, it's
> important when persisting references to it that when you restore the
> persisted thing you don't end up with a copy of the model, but rather
> the generated model itself...
>>
>> Thanks!
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434296 is a reply to message #434049] |
Thu, 30 July 2009 19:26 |
Ed Merks
Messages: 30691
Registered: July 2009 |
Senior Member |
|
|
Martin,
Generally if EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI())
== ePackage it would be better to assume it will always be available as
a registered package...
Martin Taal wrote:
> Hi Ed,
> I am persisting dynamic (non-generated) epackages, but because these
> have references to the ecore model also (i.e. to the XMLTypePackage
> most of the time), I also need to persist (in the database) the ecore
> and xmltypepackages themselves. I don't like that :-( but I need to
> because for example a persisted estructuralfeature can refer to an
> edatatype to the epackage itself (persisted in the database) or to an
> ecore type.At database level I don't know the difference... This also
> applies to epackages which belong to generated classes and 'dynamic'
> epackages.
>
> But your answer is clear!
>
> One last question, can I detect that an EPackage has a generated
> EPackage class available somewhere? I mean an EClass has an
> instancetypename but an epackage does not seem to have such a thing.
>
> gr. Martin
>
>
> Ed Merks wrote:
>> Martin,
>>
>> Comments below.
>>
>>
>> Martin Taal wrote:
>>> Hi,
>>> I am persisting ecore models in the database. Including the
>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>> correctly I also use my own EPackage.Registry which has my own
>>> instance of EcorePackage (read from the database).
>>>
>>> First a general question: is it possible/feasible to have my own
>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean will
>>> having my own EPackage.Registry solve all the issues I can have with
>>> references to the Ecore types themselves? Or are there hidden things
>>> I should be aware of (for example with the way that base edata types
>>> are resolved through the extendedmetadata)?
>> I don't think that would work well...
>>>
>>> I noticed at least one location where the
>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through a
>>> package registry. That is the XSDEcoreBuilder. I can solve this in
>>> two ways:
>>> - copy XSDEcoreBuilder and replace all the hard-references to these
>>> packages with one resolved through a packageregistry (the
>>> XSDEcoreBuilder has a package registry)
>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards and
>>> replace all references to the EcorePackage instance (incl. the
>>> edatatypes/eclasses it has etc.) with references to my own instances
>>> of EcorePackage (the same for XMLTypePackage etc.).
>> Changing code seems like a bad plan.
>>>
>>> What is the best way in your opinion (or maybe both are very unsmart
>>> and there is an other great elegant way to solve this)?
>> I'm not sure why you'd need to persist models that should be
>> ubiquitously available. In general, if you have a generated model,
>> it's important when persisting references to it that when you restore
>> the persisted thing you don't end up with a copy of the model, but
>> rather the generated model itself...
>>>
>>> Thanks!
>>>
>
>
|
|
|
| Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434299 is a reply to message #434296] |
Thu, 30 July 2009 19:28 |
Martin Taal
Messages: 5468
Registered: July 2009 |
Senior Member |
|
|
Hi Ed,
You mean generated package?
I can check it in another way also I think, just check if the instance of the EPackage==EPackageImpl.class or a subclass
(the last should be a generated one).
gr. Martin
Ed Merks wrote:
> Martin,
>
> Generally if EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI())
> == ePackage it would be better to assume it will always be available as
> a registered package...
>
>
> Martin Taal wrote:
>> Hi Ed,
>> I am persisting dynamic (non-generated) epackages, but because these
>> have references to the ecore model also (i.e. to the XMLTypePackage
>> most of the time), I also need to persist (in the database) the ecore
>> and xmltypepackages themselves. I don't like that :-( but I need to
>> because for example a persisted estructuralfeature can refer to an
>> edatatype to the epackage itself (persisted in the database) or to an
>> ecore type.At database level I don't know the difference... This also
>> applies to epackages which belong to generated classes and 'dynamic'
>> epackages.
>>
>> But your answer is clear!
>>
>> One last question, can I detect that an EPackage has a generated
>> EPackage class available somewhere? I mean an EClass has an
>> instancetypename but an epackage does not seem to have such a thing.
>>
>> gr. Martin
>>
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> Comments below.
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi,
>>>> I am persisting ecore models in the database. Including the
>>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>>> correctly I also use my own EPackage.Registry which has my own
>>>> instance of EcorePackage (read from the database).
>>>>
>>>> First a general question: is it possible/feasible to have my own
>>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean will
>>>> having my own EPackage.Registry solve all the issues I can have with
>>>> references to the Ecore types themselves? Or are there hidden things
>>>> I should be aware of (for example with the way that base edata types
>>>> are resolved through the extendedmetadata)?
>>> I don't think that would work well...
>>>>
>>>> I noticed at least one location where the
>>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through a
>>>> package registry. That is the XSDEcoreBuilder. I can solve this in
>>>> two ways:
>>>> - copy XSDEcoreBuilder and replace all the hard-references to these
>>>> packages with one resolved through a packageregistry (the
>>>> XSDEcoreBuilder has a package registry)
>>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards and
>>>> replace all references to the EcorePackage instance (incl. the
>>>> edatatypes/eclasses it has etc.) with references to my own instances
>>>> of EcorePackage (the same for XMLTypePackage etc.).
>>> Changing code seems like a bad plan.
>>>>
>>>> What is the best way in your opinion (or maybe both are very unsmart
>>>> and there is an other great elegant way to solve this)?
>>> I'm not sure why you'd need to persist models that should be
>>> ubiquitously available. In general, if you have a generated model,
>>> it's important when persisting references to it that when you restore
>>> the persisted thing you don't end up with a copy of the model, but
>>> rather the generated model itself...
>>>>
>>>> Thanks!
>>>>
>>
>>
--
With Regards, Martin Taal
Springsite/Elver.org
Office: Hardwareweg 4, 3821 BV Amersfoort
Postal: Nassaulaan 7, 3941 EC Doorn
The Netherlands
Cell: +31 (0)6 288 48 943
Tel: +31 (0)84 420 2397
Fax: +31 (0)84 225 9307
Mail: mtaal@springsite.com - mtaal@elver.org
Web: www.springsite.com - www.elver.org
|
|
|
| Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434499 is a reply to message #434299] |
Thu, 30 July 2009 19:38 |
Ed Merks
Messages: 30691
Registered: July 2009 |
Senior Member |
|
|
Martin,
I used the term registered on purpose because it's even possible to
register dynamic packages in the global package registry but I think
they should be treated the same way...
Martin Taal wrote:
> Hi Ed,
> You mean generated package?
>
> I can check it in another way also I think, just check if the instance
> of the EPackage==EPackageImpl.class or a subclass (the last should be
> a generated one).
>
> gr. Martin
>
> Ed Merks wrote:
>> Martin,
>>
>> Generally if
>> EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI()) ==
>> ePackage it would be better to assume it will always be available as
>> a registered package...
>>
>>
>> Martin Taal wrote:
>>> Hi Ed,
>>> I am persisting dynamic (non-generated) epackages, but because these
>>> have references to the ecore model also (i.e. to the XMLTypePackage
>>> most of the time), I also need to persist (in the database) the
>>> ecore and xmltypepackages themselves. I don't like that :-( but I
>>> need to because for example a persisted estructuralfeature can refer
>>> to an edatatype to the epackage itself (persisted in the database)
>>> or to an ecore type.At database level I don't know the difference...
>>> This also applies to epackages which belong to generated classes and
>>> 'dynamic' epackages.
>>>
>>> But your answer is clear!
>>>
>>> One last question, can I detect that an EPackage has a generated
>>> EPackage class available somewhere? I mean an EClass has an
>>> instancetypename but an epackage does not seem to have such a thing.
>>>
>>> gr. Martin
>>>
>>>
>>> Ed Merks wrote:
>>>> Martin,
>>>>
>>>> Comments below.
>>>>
>>>>
>>>> Martin Taal wrote:
>>>>> Hi,
>>>>> I am persisting ecore models in the database. Including the
>>>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>>>> correctly I also use my own EPackage.Registry which has my own
>>>>> instance of EcorePackage (read from the database).
>>>>>
>>>>> First a general question: is it possible/feasible to have my own
>>>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean
>>>>> will having my own EPackage.Registry solve all the issues I can
>>>>> have with references to the Ecore types themselves? Or are there
>>>>> hidden things I should be aware of (for example with the way that
>>>>> base edata types are resolved through the extendedmetadata)?
>>>> I don't think that would work well...
>>>>>
>>>>> I noticed at least one location where the
>>>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through a
>>>>> package registry. That is the XSDEcoreBuilder. I can solve this in
>>>>> two ways:
>>>>> - copy XSDEcoreBuilder and replace all the hard-references to
>>>>> these packages with one resolved through a packageregistry (the
>>>>> XSDEcoreBuilder has a package registry)
>>>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards
>>>>> and replace all references to the EcorePackage instance (incl. the
>>>>> edatatypes/eclasses it has etc.) with references to my own
>>>>> instances of EcorePackage (the same for XMLTypePackage etc.).
>>>> Changing code seems like a bad plan.
>>>>>
>>>>> What is the best way in your opinion (or maybe both are very
>>>>> unsmart and there is an other great elegant way to solve this)?
>>>> I'm not sure why you'd need to persist models that should be
>>>> ubiquitously available. In general, if you have a generated model,
>>>> it's important when persisting references to it that when you
>>>> restore the persisted thing you don't end up with a copy of the
>>>> model, but rather the generated model itself...
>>>>>
>>>>> Thanks!
>>>>>
>>>
>>>
>
>
|
|
|
| Re: XSDEcoreBuilder --> using a different EcorePackage instance [message #434501 is a reply to message #434499] |
Thu, 30 July 2009 19:41 |
Ed Merks
Messages: 30691
Registered: July 2009 |
Senior Member |
|
|
Martin,
And yes, checking the implementation class would be a reasonable trick
as well (and one I've used in the past)...
Ed Merks wrote:
> Martin,
>
> I used the term registered on purpose because it's even possible to
> register dynamic packages in the global package registry but I think
> they should be treated the same way...
>
>
> Martin Taal wrote:
>> Hi Ed,
>> You mean generated package?
>>
>> I can check it in another way also I think, just check if the
>> instance of the EPackage==EPackageImpl.class or a subclass (the last
>> should be a generated one).
>>
>> gr. Martin
>>
>> Ed Merks wrote:
>>> Martin,
>>>
>>> Generally if
>>> EPackage.Registry.INSTANCE.getEPackage(ePackage.getNsURI()) ==
>>> ePackage it would be better to assume it will always be available as
>>> a registered package...
>>>
>>>
>>> Martin Taal wrote:
>>>> Hi Ed,
>>>> I am persisting dynamic (non-generated) epackages, but because
>>>> these have references to the ecore model also (i.e. to the
>>>> XMLTypePackage most of the time), I also need to persist (in the
>>>> database) the ecore and xmltypepackages themselves. I don't like
>>>> that :-( but I need to because for example a persisted
>>>> estructuralfeature can refer to an edatatype to the epackage itself
>>>> (persisted in the database) or to an ecore type.At database level I
>>>> don't know the difference... This also applies to epackages which
>>>> belong to generated classes and 'dynamic' epackages.
>>>>
>>>> But your answer is clear!
>>>>
>>>> One last question, can I detect that an EPackage has a generated
>>>> EPackage class available somewhere? I mean an EClass has an
>>>> instancetypename but an epackage does not seem to have such a thing.
>>>>
>>>> gr. Martin
>>>>
>>>>
>>>> Ed Merks wrote:
>>>>> Martin,
>>>>>
>>>>> Comments below.
>>>>>
>>>>>
>>>>> Martin Taal wrote:
>>>>>> Hi,
>>>>>> I am persisting ecore models in the database. Including the
>>>>>> EcorePackage itself (and XMLTypePackage etc.). To handle this
>>>>>> correctly I also use my own EPackage.Registry which has my own
>>>>>> instance of EcorePackage (read from the database).
>>>>>>
>>>>>> First a general question: is it possible/feasible to have my own
>>>>>> instance of the EcorePackage (!=EcorePackage.eINSTANCE)? I mean
>>>>>> will having my own EPackage.Registry solve all the issues I can
>>>>>> have with references to the Ecore types themselves? Or are there
>>>>>> hidden things I should be aware of (for example with the way that
>>>>>> base edata types are resolved through the extendedmetadata)?
>>>>> I don't think that would work well...
>>>>>>
>>>>>> I noticed at least one location where the
>>>>>> EcorePackage/XMLTypePackage are used 'hardcoded' and not through
>>>>>> a package registry. That is the XSDEcoreBuilder. I can solve this
>>>>>> in two ways:
>>>>>> - copy XSDEcoreBuilder and replace all the hard-references to
>>>>>> these packages with one resolved through a packageregistry (the
>>>>>> XSDEcoreBuilder has a package registry)
>>>>>> - 'repair' the epackages (created by XSDEcoreBuilder) afterwards
>>>>>> and replace all references to the EcorePackage instance (incl.
>>>>>> the edatatypes/eclasses it has etc.) with references to my own
>>>>>> instances of EcorePackage (the same for XMLTypePackage etc.).
>>>>> Changing code seems like a bad plan.
>>>>>>
>>>>>> What is the best way in your opinion (or maybe both are very
>>>>>> unsmart and there is an other great elegant way to solve this)?
>>>>> I'm not sure why you'd need to persist models that should be
>>>>> ubiquitously available. In general, if you have a generated model,
>>>>> it's important when persisting references to it that when you
>>>>> restore the persisted thing you don't end up with a copy of the
>>>>> model, but rather the generated model itself...
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>
>>>>
>>
>>
|
|
|
Goto Forum:
Current Time: Wed Dec 11 16:13:02 GMT 2019
Powered by FUDForum. Page generated in 0.01740 seconds |
Search
Help
Register
Login
Home
