What do you think about making "extensible" the default behavior and adding an option "OPTION_NOT_EXTENSIBLE" or "OPTION_NO_EXTENSION" for those folks that don't want the "extensible" overhead?
----- Original Message ---- From: Frank Budinsky <[EMAIL PROTECTED]> To: [email protected] Cc: [email protected] Sent: Wednesday, July 5, 2006 12:06:45 PM Subject: Re: DataObjectImpl.setEClass(EClass) throws UnsupportedOperationException() Ron Gavlin <[EMAIL PROTECTED]> wrote on 07/05/2006 10:09:51 AM: > Greetings, > > In order to support mixed static/dynamic models, I made changes to > SDOXSDEcoreBuilder as well as the changes listed in my previous > message. I'm investigating whether I can contribute these back to > the community. I'll let you know when I have more information. That would be great if you can. If so, open a JIRA for the issue and attach a patch. > The changes made to SDOXSDEcoreBuilder could just as easily have been > applied to EMF's EcoreBuilder. I think EMF itself would probably > benefit from this mixed-model support. Since you haven't said exactly what your change to SDOXSDEcoreBuilder actually does, I can't really comment on whether or not it would be a good addition to EMF itself. If it's some kind of annotation to choose on a per-complexType basis whether to support a mixed dynamic/static base class, I think that since EMF currently has no static-only optimized base class, I'm not sure they'd want it there ... but you might want to suggest it on the EMF newsgroup to let them comment. > > Do you have any thoughts about modifying the code generator to > support this new base class? Once we have the ExtensibleDataObjectImpl base class available, then I was thinking of a simple command line option (-extensible or something like that) to generate using it. This would apply to all the types, not the fine grain control you're suggesting below. > Also any thoughts about offering the > ability to INDIVIDUALLY flag/annotate specific schema types as > "extensible" to enable code-generation optimizations? It doesn't sound like a bad idea if people would find it useful. Adding an annotation for this to the SDO spec would be harder since it's an implementation detail, but making it a Tuscany-specific extension shouldn't be a problem. > > - Ron > > ----- Original Message ---- > From: Ron Gavlin <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, June 30, 2006 4:58:26 PM > Subject: Re: DataObjectImpl.setEClass(EClass) throws > UnsupportedOperationException() > > > Frank, > > Thanks, that helped. > > I performed the following steps and the problem disappeared. > > 1. Added ExtensibleDataObject to the model (copied from DynamicDataObject) > 2. Re-generated code from model into a work area and applied updates > to relevant tuscany SDO classes [SDOFactory(Impl), SDOPackage(Impl)] > 3. Copied DynamicDataObjectImpl to ExtensibleDataObjectImpl > 4. Removed eStaticFeatureCount() method > 5. Modified ExtensibleDataObjectImpl eStaticClass() and FactoryImpl. > basicCreate to work with ExtensibleDataObjectImpls. > 6. Modified my "InfoTypeImpl" class to extend > ExtensibleDataObjectImpl instead of DataObjectImpl. > 7. Executed XMLHelper load test to ensure the data object loads > successfully using my mixed static/dynamic model...worked like a champ. > > What option were you thinking of adding to the code generator to > trigger using this new base class? Along with this course-grained > approach, does it also make sense to offer the ability to > INDIVIDUALLY flag/annotate specific schema types as "extensible"? Is > there a significant performance/memory win using a DataObjectImpl > vs. ExtensibleDataObjectImpl? > > Thanks for all your help. > > - Ron > > > > ----- Original Message ---- > From: Frank Budinsky <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, June 30, 2006 2:17:58 PM > Subject: Re: DataObjectImpl.setEClass(EClass) throws > UnsupportedOperationException() > > > A little more background: > > In EMF: > > 1. BasicEObjectImpl is a base implementation of the EObject interface. It > doesn't allocate any storage - it expects subclasses to do that. > 2. EObjectImpl is the EMF default base class for generated classes. It is > a flexible implementation that allows the generated classes to be extended > by dynamic types. > 3. DynamicEObjectImpl extends EObjectImpl to optimize a few things for the > pure-dynamic case. > 4. EDataObjectImpl is a subclass of EObjectImpl that also implements the > SDO DataObject interface - in Tuscany we don't have separate > implementation classes to implement the DataObject interface because all > our implementation classes are for that purpose. > > in Tuscany: > > 1. DataObjectImpl is a subclass of EMF's BasicEObjectImpl that implements > the DataObject interface and allocates the absolute minimum storage. > Unlike EObjectImpl, which is an analous class for EMF (EObject's), it is > not intended to be extended by dynamic types. > 2. DynamicDataObjectImpl is analogous to DynamicEObjectImpl in EMF, but > for DataObjects. > > So, the ExtensibleDataObjectImpl class I've suggested is something between > DataObjectImpl and DynamicDataObjectImpl that would be the DataObject > equivalent of EObjectImpl. > > I hope this helps. > Frank. > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 06/30/2006 01:12:58 PM: > > > Frank, > > > > Does the proposed relationship between ExtensibleDataObjectImpl and > > DataObjectImpl somewhat mirror the relationship between EMF classes > > EObjectImpl and BasicEObjectImpl? At first glance, it appears > > EObjectImpl adds, amongst other things, support for this dynamic > > EClass. Would I look at the EMF/SDO 1.0 EDataObjectImpl class (which > > extends EObjectImpl) to get some ideas? > > > > - Ron > > > > ----- Original Message ---- > > From: Ron Gavlin <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Friday, June 30, 2006 12:35:21 PM > > Subject: Re: DataObjectImpl.setEClass(EClass) throws > > UnsupportedOperationException() > > > > > > Hi Frank, > > > > I added JIRA feature request "TUSCANY-513" to track this issue. > > Unfortunately, I don't think I have the EMF experience required to > > whip-up such a class. Off the top of your head, do you have an idea > > what methods the class would probably need to implement to get the job > done? > > > > - Ron > > > > ----- Original Message ---- > > From: Frank Budinsky <[EMAIL PROTECTED]> > > To: [email protected] > > Sent: Friday, June 30, 2006 12:05:34 PM > > Subject: Re: DataObjectImpl.setEClass(EClass) throws > > UnsupportedOperationException() > > > > > > Hi Ron, > > > > Looking at this, it looks like the problem is that you're trying to > create > > dynamic subclasses of statically generated types. The bad news is that > > Tuscany doesn't currently support that. The good news is that it's not > too > > hard to add the support. > > > > The problem is that currently Tuscany only has these two primary > > DataObject implementation classes: > > > > 1. DataObjectImpl - is the base class used for statically generated > types. > > It is highly tuned for performance and footprint, so, unlike the base > > class in SDO1 (actually EMF) it doesn't support dynamic extensions. > > > > 2. DyamicDataObjectImpl - is the class used to support dynamic SDOs. It > is > > designed for pure dynamic types, not a mixture of static and dynamic. > > > > To support what you want, we will need another base class, say > > ExtensibleDataObjectImpl, that is quite similar to > DynamicDataObjectImpl, > > but doesn't make the assumption that eStaticFeatureCount() is 0. My > guess > > is that there are only a few simple method overrides needed in this > class. > > Maybe you would like to try to prototype such a class yourself and hand > > modify your generated classes to extend from it? If you did that and > > tested it, you could submit a patch and we could then very quickly add a > > > generator option to use it (maybe even make it the default). If you'd > like > > to help with this, it would be very much appreciated! > > > > At any rate, you should probably open a JIRA feature request for this. > > > > Thanks, > > Frank > > > > Ron Gavlin <[EMAIL PROTECTED]> wrote on 06/30/2006 10:13:44 AM: > > > > > Frank, > > > > > > I am working with a mixed static/dynamic model similar to the one > > > listed at the bottom of this post. The http://example.org/ord > > > namespace is statically registered and has code-generated classes. The > > > > http://example.org/info/zipcode and http://example.org/info/street > > > namespaces are dynamically registered with no code-generated > > > classes. When I attempt to load the Sample Instance (chapter04.xml), > > > I receive an UnsupportedOperationException thrown from > > > DataObjectImpl.setEClass(EClass). The DataObjectImpl throwing the > > > exception is an instance of "InfoTypeImpl" from the "ord" > > > namespace/ePackage. The EClass parameter is "InfoType" from the > > > "zipcode" namespace. This instance document loads fine using EMF/SDO > > > 1.0. Any suggestions I can try to work-around this problem? > > > > > > - Ron > > > > > > > > > Sample Instance (chapter04.xml) > > > <ord:order xmlns:ord="<http://example.org/ord>";;;;; > > > xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>";;;;; > > > xsi:schemaLocation="<http://example.org/ord> chapter04ord1.xsd"> > > > <ord:number>123ABBCC123</ord:number> > > > <ord:customer> > > > <ord:name>Pat Walmsley</ord:name> > > > <ord:number>15465</ord:number> > > > <info xsi:type="ns1:InfoType" xmlns="" > > > xmlns:ns1="<http://example.org/info/zipcode>";;;;;> > > > <zipcode>21043</zipcode> > > > </info> > > > </ord:customer> > > > <ord:customer> > > > <ord:name>Priscilla Walmsley</ord:name> > > > <ord:number>15466</ord:number> > > > <info xsi:type="ns1:InfoType" xmlns="" > > > xmlns:ns1="<http://example.org/info/street>";;;;;> > > > <street>341 Duckworth Way</street> > > > </info> > > > </ord:customer> > > > <ord:items> > > > <product> > > > <number>557</number> > > > <name>Short-Sleeved Linen Blouse</name> > > > <size system="US-DRESS">10</size> > > > <color value="blue"/> > > > </product> > > > </ord:items> > > > </ord:order> > > > Schema Document 1 (chapter04ord1.xsd) > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;; > > > targetNamespace="<http://example.org/ord>";;;;;; > > > xmlns="<http://example.org/ord>";;;;;; > > > xmlns:prod="<http://example.org/prod>";;;;;; > > > elementFormDefault="qualified"> > > > <xsd:import namespace="<http://example.org/prod>";;;;;; > > > schemaLocation="chapter04prod.xsd"/> > > > <xsd:simpleType name="OrderNumType"> > > > <xsd:restriction base="xsd:string"/> > > > </xsd:simpleType> > > > <xsd:complexType name="InfoType"/> > > > <xsd:complexType name="CustomerType"> > > > <xsd:sequence> > > > <xsd:element name="name" type="CustNameType"/> > > > <xsd:element name="number" type="xsd:integer"/> > > > <xsd:element name="info" type="InfoType" form="unqualified"/> > > > </xsd:sequence> > > > </xsd:complexType> > > > <xsd:simpleType name="CustNameType"> > > > <xsd:restriction base="xsd:string"/> > > > </xsd:simpleType> > > > <xsd:element name="order" type="OrderType"/> > > > <xsd:complexType name="OrderType"> > > > <xsd:sequence> > > > <xsd:element name="number" type="OrderNumType"/> > > > <xsd:element name="customer" type="CustomerType" > > > maxOccurs="unbounded"/> > > > <xsd:element name="items" type="prod:ItemsType"/> > > > </xsd:sequence> > > > </xsd:complexType> > > > </xsd:schema> > > > Schema Document 2 (chapter04infozipcode.xsd) > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;; > > > xmlns:ord="<http://example.org/ord>";;;;;; > > > xmlns="<http://example.org/info/zipcode>";;;;;; > > > targetNamespace="<http://example.org/info/zipcode>";;;;;; > > > elementFormDefault="unqualified"> > > > <xsd:import namespace="<http://example.org/ord>";;;;;; > > > schemaLocation="chapter04ord1.xsd"/> > > > <xsd:complexType name="InfoType"> > > > <xsd:complexContent> > > > <xsd:extension base="ord:InfoType"> > > > <xsd:sequence> > > > <xsd:element name="zipcode" type="xsd:string"/> > > > </xsd:sequence> > > > </xsd:extension> > > > </xsd:complexContent> > > > </xsd:complexType> > > > </xsd:schema> > > > Schema Document 3 (chapter04infostreet.xsd) > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;; > > > xmlns:ord="<http://example.org/ord>";;;;;; > > > xmlns="<http://example.org/info/street>";;;;;; > > > targetNamespace="<http://example.org/info/street>";;;;;; > > > elementFormDefault="unqualified"> > > > <xsd:import namespace="<http://example.org/ord>";;;;;; > > > schemaLocation="chapter04ord1.xsd"/> > > > <xsd:complexType name="InfoType"> > > > <xsd:complexContent> > > > <xsd:extension base="ord:InfoType"> > > > <xsd:sequence> > > > <xsd:element name="street" type="xsd:string"/> > > > </xsd:sequence> > > > </xsd:extension> > > > </xsd:complexContent> > > > </xsd:complexType> > > > </xsd:schema> > > > Schema Document 4 (chapter04prod.xsd) > > > <xsd:schema xmlns:xsd="<http://www.w3.org/2001/XMLSchema>";;;;;; > > > xmlns="<http://example.org/prod>";;;;;; > > > targetNamespace="<http://example.org/prod>";;;;;; > > > elementFormDefault="unqualified"> > > > <xsd:complexType name="ItemsType"> > > > <xsd:sequence> > > > <xsd:element name="product" type="ProductType"/> > > > </xsd:sequence> > > > </xsd:complexType> > > > <xsd:complexType name="ProductType"> > > > <xsd:sequence> > > > <xsd:element name="number" type="xsd:integer"/> > > > <xsd:element name="name" type="xsd:string"/> > > > <xsd:element name="size" type="SizeType"/> > > > <xsd:element name="color" type="ColorType"/> > > > </xsd:sequence> > > > </xsd:complexType> > > > <xsd:complexType name="SizeType"> > > > <xsd:simpleContent> > > > <xsd:extension base="xsd:integer"> > > > <xsd:attribute name="system" type="xsd:string"/> > > > </xsd:extension> > > > </xsd:simpleContent> > > > </xsd:complexType> > > > <xsd:complexType name="ColorType"> > > > <xsd:attribute name="value" type="xsd:string"/> > > > </xsd:complexType> > > > </xsd:schema> > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
