Hi Dave,
I've just tried the fix.
I have this error
[wigos@WIGOS generateDS]$ sudo python gends_run_gen_django.py -s -f -v -p
/var/opt/generateDS/generateDS.py /home/wigos/projects/
generateDS/wmdr/xsd/wmdr.xsd
[sudo] password for wigos:
schema_name_stem: wmdr
bindings_file_name: wmdrlib.py
removing: wmdrlib.py
removing: wmdrlib.pyc
*** running /var/opt/generateDS/generateDS.py -f -o wmdrlib.py
--member-specs=list /home/wigos/projects/generateDS/wmdr/xsd/wmdr.xsd
/var/opt/generateDS/generateDS.py -f -o wmdrlib.py --member-specs=list
/home/wigos/projects/generateDS/wmdr/xsd/wmdr.xsd
*** error ***
*** warning. Removing child with duplicate name: "Boolean"
*** warning. Removing child with duplicate name: "AbstractObject"
*** warning. Removing child with duplicate name: "Process"
*** warning. Removing child with duplicate name: "RangeBounds"
*** error ***
*** running ./gends_extract_simple_types.py -f /home/wigos/projects/
generateDS/wmdr/xsd/wmdr.xsd
./gends_extract_simple_types.py -f /home/wigos/projects/
generateDS/wmdr/xsd/wmdr.xsd
*** running ./gends_generate_django.py -f wmdrlib
./gends_generate_django.py -f wmdrlib
*** error ***
Traceback (most recent call last):
File "./gends_generate_django.py", line 176, in <module>
main()
File "./gends_generate_django.py", line 170, in main
generate_model(options, module_name)
File "./gends_generate_django.py", line 97, in generate_model
cls.generate_model_(wrtmodels, wrtforms, unique_name_map)
AttributeError: type object 'AbstractCRSType' has no attribute
'generate_model_'
*** error ***
[wigos@WIGOS generateDS]$
Did I miss something when applying the fix?
Kind regards
*Rémy GIBAULT*
2017-06-05 23:39 GMT+02:00 Dave Kuhlman <dkuhl...@davekuhlman.org>:
> Rémy,
>
> Here are the fixes we discussed. These fixes should:
>
> 1. Generate valid models for element definitions that contain xs:any
> child elements.
>
> 2. Generate models and forms that have unique names even when case
> is ignored.
>
> I suspect, however, that when you get farther into your work, you
> will find that our solution for the problem caused by xs:any will
> need more attention. Generating a django.db.models.CharField for
> each of these child elements is likely not going to cover your
> needs. When you get to that point and, especially, if you have some
> ideas about what can be done to improve this, please contact me.
>
> And, if you have suggestions or problems with this fix, please let
> me know.
>
> Thanks for your help with these issues.
>
> Dave
>
> On Sat, Jun 03, 2017 at 01:11:45PM +0200, Rémy Gibault wrote:
> > Hi Dave,
> > My week-end is excellent.
> > I agree with both proposals.For item 1, I really don't know. I'm a
> newbie
> > in django! For item 2, I don't see any better options for the while.(
> > Before contacting you, I started correcting duplicate class names by
> > adding some incremental postfix. ).
> > I wish you a good week-end.
> > Rémy
> >
> > Le samedi 3 juin 2017, Dave Kuhlman <dkuhl...@davekuhlman.org> a
> > écrit :
> >
> > Rémy,
> >
> > I've made some changes in an attempt to handle these issues. I'll
> > send you a patch in a couple of days, after I've worked on it and
> > thought on it a bit more. In the meantime, any guidance is welcome.
> >
> > Here are a few notes.
> >
> > Item 1
> > -------
> >
> > > 1. models.py contains several lines like these ones:
> > >
> > > remoteSchema = models.CharField(max_length=1000, blank=True,
> > null=True)
> > > * = models.CharField(max_length=1000, )*
> >
> > Thanks for catching this. While working on this one, I found that
> > there is a related problem in generateDS.py, itself. I've fixed
> > that one and also made a change in the django support. Our problem
> > is that this error was produced by a element member defined with
> > xs:any, for example:
> >
> > <xs:complexType name="GenericMetaDataType" mixed="true">
> > <xs:annotation>
> > <xs:appinfo>deprecated</xs:appinfo>
> > </xs:annotation>
> > <xs:complexContent mixed="true">
> > <xs:extension base="gml:AbstractMetaDataType">
> > <xs:sequence>
> > <xs:any processContents="lax"
> > minOccurs="0" maxOccurs="unbounded"/>
> > </xs:sequence>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > The occurance of xs:any in this complexType definition means that
> > any content can appear in this element type, that is, any element
> > type can be inside a GenericMetaDataType element, in this case.
> > That nested element does not even have a name that we can use.
> >
> > So, I have no idea how to handle that for django. Perhaps you have
> > a suggestion.
> >
> > What I've done, as a partial solution is to generate something like
> > the following:
> >
> > class GenericMetaDataType_model(models.Model):
> > __ANY__ = models.CharField(max_length=1000,
> > blank=True, null=True)
> >
> > def __unicode__(self):
> > return "id: %s" % (self.id, )
> >
> > That really does not handle the intent of xs:any. But, I don't know
> > what would. A models.ForeignKey(), perhaps?
> >
> > Item 2 -- Duplicate names
> > ---------------------------
> >
> > I looked at wmdr.xsd. I pulled in all the parts that it
> > (recursively) includes (using xs:include and xs:import) I did this
> > by using process_includes.py in the generateDS distribution to
> > accumulate them all. There are indeed (complexType) element
> > definitions whose names are duplicates when we ignore case.
> >
> > But, XML element names are case sensitive. And, in Python, the
> > names of the classes that generateDS.py generates to represent them
> > are case sensitive also.
> >
> > So, for the django work, we need to do something to "unique-ify"
> > these names.
> >
> > I could implement a mechanism that would add something to the end of
> > any duplicate name to make it unique. That would not take a lot of
> > code. It could be something like this:
> >
> > previous_names = set()
> >
> > ...
> >
> > if name in previous_names:
> > name = uniquify_name(name, previous_names)
> > previous_names.add(name)
> >
> > ...
> >
> > def uniquify_name(name, previous_names):
> > count = 0
> > while True:
> > count += 1
> > new_name = '%s_%03d' % (name, count)
> > if new_name not in previous_names:
> > break
> > return new_name
> >
> > With this method, we'd end up with names like: "original_name_001",
> > "original_name_002", etc.
> >
> > Would that be a reasonable solution? One down-side is that it would
> > make some model type names *not* equal to their names in the schema,
> > although those names would be somewhat predictable. What do you
> > think? Any other ideas?
> >
> > I'll start looking into that.
> >
> > Hope your weekend is (or has been) a good one.
> >
> > Dave
> >
> > On Thu, Jun 01, 2017 at 06:44:35PM +0200, Rémy Gibault wrote:
> > > Sorry Dave,
> > >
> > > That's me again.
> > >
> > > As I said earlier, both models and forms have been generated
> > > using gends_run_gen_django.py.
> > > You'll find the models.py file as attachment.
> > >
> > > Now I'm trying to migrate the database.
> > >
> > > python manage.py makemigrations metadata
> > >
> > > So far I'm facing 2 different kinds of error:
> > >
> > > 1. models.py contains several lines like these ones:
> > >
> > > remoteSchema = models.CharField(max_length=1000, blank=True,
> > null=True)
> > > * = models.CharField(max_length=1000, )*
> > >
> > >
> > > Migration fails with "IndentationError:
> > unexpected indent"
> > > Some variable is missing at the begining.
> > > I am not proud of me but I have commented these
> > lines...
> > >
> > > 2. Many classes are generated twice with approximatively same name
> > (just
> > > one character differs as upper case or lowercase) but different
> > content:
> > >
> > >
> > > RuntimeError: Conflicting 'equipmenttype_model' models in
> application
> > > 'metadata': <class 'metadata.models.*E*quipmentType_model'> and
> <class
> > > 'metadata.models.*e*quipmentType_model'>.
> > >
> > > RuntimeError: Conflicting 'facilitysettype_model' models in
> > application
> > > 'metadata': <class 'metadata.models.*F*acilitySetType_model'> and
> > <class
> > > 'metadata.models.*f*acilitySetType_model'>.
> > >
> > > I'm a little bit puzzled.
> > > Is that due to errors in the original xsd?
> > >
> > > *Rémy *
> > >
> > > 2017-05-31 10:37 GMT+02:00 Rémy Gibault <gibau...@mfi.fr>:
> > >
> > > > Thank you so much for being so reactive !
> > > >
> > > > Both models and forms have been generated.
> > > >
> > > > Now it is up to me to make good use of them...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > *Rémy *
> > > >
> > > >
> > > > 2017-05-30 22:10 GMT+02:00 Dave Kuhlman <
> dkuhl...@davekuhlman.org>:
> >
> > --
> >
> > Dave Kuhlman
> > http://www.davekuhlman.org
> >
> > --
> >
> > Rémy GIBAULT
> > Responsable de Pôle Data Center
> > Head of Data Management Systems
> > -------------------------------------------------------------------
> > METEO FRANCE INTERNATIONAL
> > 9 rue Michel Labrousse, 31100 Toulouse, France
> > Tel: + 33 5 61 43 29 79
> > Skype: mfi_gibaultr
> > Web : www.mfi.fr
> > The information in this e-mail is confidential. The contents may not
> be
> > disclosed or used by anyone other than the addressee. If you are not
> > the intended recipient, please notify us immediately and delete this
> > message from your system without printing or copying
>
> --
>
> Dave Kuhlman
> http://www.davekuhlman.org
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
