I've changed the hard coded limit mentioned previously to 10000. Looking at
the generated files, I have noticed that the hacked and normal files differ
in the following way.
In the xsd file, there a several sections structured in the following
manner:
<xsd:complexType name="ListCommonDeviceConfigReq">
<xsd:sequence>
<xsd:element name="searchCriteria">
<xsd:annotation>
<xsd:documentation>
Atleast one element under searchCriteria has to be mentioned
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="returnedTags" type="axlapi:LCommonDeviceConfig" minOccurs
="1"/>
<xsd:element name="skip" type="xsd:unsignedLong" minOccurs="0">
<xsd:annotation>
<xsd:documentation>It will be used only when first tag is specified.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="first" type="xsd:unsignedLong" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute use="optional" name="sequence" type="xsd:unsignedLong"/>
</xsd:complexType>
The thing to note is that all these complexType elements like "
ListCommonDeviceConfigReq" have the same sub-element called "searchCriteria"
which in turn contains an anonymous complexType.
In the "hacked" output file (using process_includes), there 135 classes
called "searchCriteriaTypeX" (X is 1->135). The classes representing the
enclosing tags each have their own searchCriteria class. In the
"no_process_includes" version of the output file, there is only one
SearchCriteria class which is referred to in each of the classes
representing the enclosing tags.
Thanks
On Mon, Oct 22, 2012 at 3:49 PM, Daniel Browne <
daniel.bro...@voss-solutions.com> wrote:
> I'm using generateDS to process a large XSD file which does not have any
> includes or imports in it. It does have what I understand to be anonymous
> complex types (no "name" attribute). When I process the file normally I get
> the following error:
>
> # generateDS.py -o output.py -s outputsubs.py input.xsd
> Traceback (most recent call last):
> File "/usr/local/bin/generateDS.py", line 5, in <module>
> pkg_resources.run_script('generateDS==2.7c', 'generateDS.py')
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 499, in
> run_script
> self.require(requires)[0].run_script(script_name, ns)
> File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1235, in
> run_script
> execfile(script_filename, namespace, namespace)
> File
> "/usr/local/lib/python2.7/dist-packages/generateDS-2.7c-py2.7.egg/EGG-INFO/scripts/generateDS.py",
> line 4721, in <module>
> main()
> File
> "/usr/local/lib/python2.7/dist-packages/generateDS-2.7c-py2.7.egg/EGG-INFO/scripts/generateDS.py",
> line 4715, in main
> processIncludes, superModule=superModule)
> File
> "/usr/local/lib/python2.7/dist-packages/generateDS-2.7c-py2.7.egg/EGG-INFO/scripts/generateDS.py",
> line 4445, in parseAndGenerate
> inpath=xschemaFileName)
> File
> "/usr/local/lib/python2.7/dist-packages/generateDS-2.7c-py2.7.egg/EGG-INFO/scripts/process_includes.py",
> line 49, in process_include_files
> prep_schema_doc(infile, outfile, inpath, options)
> File
> "/usr/local/lib/python2.7/dist-packages/generateDS-2.7c-py2.7.egg/EGG-INFO/scripts/process_includes.py",
> line 203, in prep_schema_doc
> raise_anon_complextypes(root2)
> File
> "/usr/local/lib/python2.7/dist-packages/generateDS-2.7c-py2.7.egg/EGG-INFO/scripts/process_includes.py",
> line 301, in raise_anon_complextypes
> type_name = unique_name(type_name, def_names)
> File
> "/usr/local/lib/python2.7/dist-packages/generateDS-2.7c-py2.7.egg/EGG-INFO/scripts/process_includes.py",
> line 316, in unique_name
> raise RaiseComplexTypesError('duplicate name count max (100) exceeded')
>
> I see that the code in process_includes attempts to raise the anonymous
> complex types to the top level and make their elements reference them. It
> fails after 100 instances (hard coded).
>
> If I process the file with the --no-process-includes parameter, output
> is successfully generated.
>
> What I don't understand is why the same error is not generated in the
> successful case? The elements causing the issue are not imported or
> included, they are in the main file. Why is process_includes processing the
> main file in a different way to generateDS?
>
>
> Thanks
> --
>
>
> <http://www.voss-solutions.com/>
>
> *
> Daniel Browne
> *
>
> Developer / Design Lead
>
> VOSS Development
> Mobile: +27 (0) 79 293 2044
> daniel.bro...@voss-solutions.com
>
> <https://twitter.com/voss_solutions> <http://www.linkedin.com/company/voss>
> <http://www.facebook.com/pages/VOSS-Solutions/254816747898652?sk=wall>
>
>
--
<http://www.voss-solutions.com/>
*
Daniel Browne
*
Developer / Design Lead
VOSS Development
Mobile: +27 (0) 79 293 2044
daniel.bro...@voss-solutions.com
<https://twitter.com/voss_solutions> <http://www.linkedin.com/company/voss>
<http://www.facebook.com/pages/VOSS-Solutions/254816747898652?sk=wall>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
