Question: What does `Type with name doubleBaseType already exists` mean?

[MarAlder]

I'm a bit stumped. Why do I get the following message with the CPACS 3.5 schema?

Exception: Type with name doubleBaseType already exists

cpacs_tigl_gen/src/lib/SchemaParser.cpp

Lines 313 to 314 in 5661239

	if (m_types.types.find(name) != std::end(m_types.types))
	throw std::runtime_error("Type with name " + name + " already exists");

What could have changed in the 3.5 schema compared to 3.3 that triggers this problem?

cpacs_schema.zip

[MarAlder]

Further testing has revealed that it is due to the alphabetic sorting of the types that I introduced with CPACS 3.5 using a Python script.

Applied alphabetic sorting to CPACS 3.4, it shows that the C++ code is generated when I move doubleBaseType, stringArrayBaseType, and stringVectorBaseType to the beginning of the XSD.

• cpacs_schema_working.zip
• cpacs_schema_notWorking.zip

Does this give an indication of what might be buggy about the CPACSGen code shown above?

[merakulix]

Hi, I'll test the schema files you send, and check this also with my PR.

I could not trace back yet why this occurs occasionally, as more of an XSD newby I don't fully understand yet why the generator needs to read the element types and attributes in the specific order it does, to store the information of the types.

I would assume, that the function throwing that exception could come across the same xsd element name, reading the types in this order: The simple type, the complex type, the element types( which calls readInlineType, which calls readSimple type again (in which case the element could already have been read and stored) for each child (also the doubleBase child, and all that have attributes of that type) as I understand.
Then I did not find exception handling for this scenario, that I think could occur if you have attributes with types you created as elements in your xsd, and need to read both: attribute types and the xsd elements you created, and in this case the exception should be caught and not end the process.

But if that assumption is true, and the exception is not caught, it would also be thrown when you put the doubleBaseType elements first in your file I think, so there could be another reason...

I'll keep you update wether I can find out what happens.

[merakulix]

Ok, so far I can confirm the error with the schema files you sent. If I surround the function calls with a try catch block I get this:

I expected, that these types would be a problem as well, but I don't know what this message means yet:

Exception: Unknown type: posExcl0DoubleBaseType

Why should this type not be found, it is thrown in TypeSystem::resolveTypes() and TypeSystem::resolveComplexTypes(). Is it special in some way so the if statements miss it?

[merakulix]

@MarAlder I tested what would happen if I caught the Errors and let the processes pass.
I can make the Generator build files like that. But (not very surprisingly) the output is messed up, produces no valid code (writes types that don't exist or were not declared in the written file etc...) .

Either: The uncaught Errors can be handled in a way that nothing gets messed up. One would have to know which routines to stop (writing lines, in the actual files, that should not be written, or storing information in memory/typeSystem) when an Error is thrown.
Or: The Code generator really gets messed up with the new order of the XSD because the implementation relies on the former order. So it's creating a wrong order storing the types in the type system, or reading the types in the wrong order to print them in the writing routines or even both. This would require rewriting some routines.

Both: Would have been nice to find a quick fix, but for me it's hard to estimate how quick this could be fixed.