That's probably a good idea. Making flexibility the default and optimal performance an option is probably the best approach.
Frank. Ron Gavlin <[EMAIL PROTECTED]> wrote on 07/05/2006 12:46:29 PM: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
