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
------------------------------------------------------------------------------
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
