hi john,
john guthrie wrote:
> actually i do see some odd stuff. things that i define as complex types in
> the schema:
>
> <xs:complexType name="equipment">
> <xs:attribute name="equipment_guid" type="sp:string32"/>
> <xs:attribute name="type" type="sp:string20"/>
> <xs:attribute name="producer" type="sp:string20"/>
> <xs:attribute name="make" type="sp:string20"/>
> <xs:attribute name="model" type="sp:string20"/>
> ...
>
> end up extending themselves in the generated code:
>
> @SuppressWarnings("serial")
> public class Equipment extends Equipment
> implements java.io.Serializable
> {
>
That is a typical example of a naming collision. Most likely you do have
both a (complex) type definition and an element definition (global or
local) that in your XML schema carry the name 'equipment' and/or
Equipment. During code generation, Castor will try to resolve the XML
artefact names to proper class names, 'Equipment' in your case. As such,
one will overwrite the other.
To avoid those collisions, please use a binding file during code
generation. I do not know anything about the size of your XMl schema,
but I'd try to define e.g. a '-Type' suffix for all complex types and
see how far you get. Alternatively, if this is about just a handful of
collisions, you can use a finite set of explicit e.g. <elementBinding>
to resolve those manually.
Does this make any sense ?
Werner
>
>
> On Wed, Dec 3, 2008 at 9:57 AM, john guthrie <[EMAIL PROTECTED]> wrote:
>
>> well, the generated code looks a lot different from my current data model
>> ...
>>
>> 1) lots of enumerations for attributes that are, er, enumerated in the
>> schema that i hadn't bothered to "lock down" in the model (i.e. i had them
>> as strings). that's fine, of course (it's a good thing, actually)
>>
>> 2) i did have everything underscore-separated in the schema and camel-cased
>> in the data model.
>>
>> 3) i also had all my lists of child objects as that - lists. but in the xml
>> i defined that as a 'choice' of sequences, so that became a list of lists.
>> fair enough, that is what the xsd really translates to
>>
>> so nothing to stop me, but its more work than i had hoped for (it's a
>> fairly big data model)
>>
>> one other thing. i tried to set the generateMapping property in the ant
>> task to 'yes'. it's a documented option, but the ant task complained
>> that generateMapping was not an option. i looked at the ant task and sure
>> enough, there is a _generateMapping boolean, but no setter for it. so i
>> added one and rebuilt. the task ran fine, but if it gerneated the mapping
>> file i don't know where it did so.
>>
>> thanks
>>
>> john
>> On Wed, Dec 3, 2008 at 9:01 AM, Werner Guttmann <[EMAIL PROTECTED]>wrote:
>>
>>> let me know about your progress.
>>>
>>> Werner
>>>
>>> john guthrie wrote:
>>>> using the source generator would be preferable from a maintenance view
>>> as
>>>> well i'm now thinking. i'm setting up the ant task now, i'll post when i
>>>> make some progress.
>>>>
>>>> thanks.
>>>>
>>>> john
>>>>
>>>> On Wed, Dec 3, 2008 at 8:04 AM, Werner Guttmann <
>>> [EMAIL PROTECTED]>wrote:
>>>>> john,
>>>>>
>>>>> If that's the case, this should be 100% achievable. Castor XML (code
>>>>> generator) generates 100& POJOs from the XML schema. It should be
>>>>> straight-forward to map those to a relational database using Hibernate.
>>>>> If you happen to have problems with this, I'd like to know.
>>>>>
>>>>> Werner
>>>>>
>>>>> john guthrie wrote:
>>>>>> On Wed, Dec 3, 2008 at 7:46 AM, Werner Guttmann <
>>> [EMAIL PROTECTED]
>>>>>> wrote:
>>>>>>
>>>>>>>> i could see what castor generates and maybe
>>>>>>>> coerce that into something hibernate likes i guess
>>>>>>> When you say generate, I assume you are talking about (un)marshalling
>>> to
>>>>>>> and from XML, right ?
>>>>>>>
>>>>>> my goof, i was talking about using the source code generator, as you
>>>>>> suggested, and seeing how far that is from what hibernate likes.
>>>>>> john
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
