On 20/03/2013 10:56, Dave Angel wrote:
On 03/20/2013 01:58 AM, Frank Millman wrote:
On 19/03/2013 17:03, Dave Angel wrote:
On 03/19/2013 10:29 AM, Frank Millman wrote:
On 19/03/2013 14:46, Dave Angel wrote:
  <SNIP>
In putting them there, you are making two assumptions.  One is that only
one user will ever run this, and two is that the user will not need two
sets of those 'schemas'.  If the user is tracking two different
companies, each with the same code, but different xml and different
database, this would be the wrong place to put it.  But it's up to you
to decide those assumptions, not I.


Maybe I did not explain very well. I fully expect a large number of
users, tracking a large number of companies, to access the same schema
file at the same time.

So the scheme does NOT describe an individual company, but something
more general?  Presumably there's a separate database per company?  Why
then is the schema separately stored in each database?


In fact I use lxml to parse the xml once it has been read from the
database and decompressed. There are a limited number of 'types' of xml
file (form definition, service definition, report definition, etc), and
each type has its own schema. lxml will use a validating schema if you
pass the path to the xsd file as a parameter to the parser. I create
separate parsers, one for each type, when the program starts. But I
still need to tell it where to find the xsd file.

They are stored in a sub-directory called 'schemas'.

Clearly I don't understand your model well enough to advise you one way
or the other.  All I can do is ask questions whose answers might remind
you of things you know but I do not.

This code is running on a server, with simultaneous users?  And all
users who run it will be using identical xml, which will only be updated
when a new version of the script is installed?  And each time a user
starts the application, you read the xml from the database, write it to
a sub-directory 'schemas'  and subsequently in the run you access it
with lxml?  You've considered what happens when one user is creating the
files, while another user is still accessing them?

Are these 'files' so enormous that you can't just use in-memory file
objects?

The analogy to global variables must be clear.  They're fine if they're
constant.  But as soon as you have multiple threads making new versions
of them, everything can easily get out of whack.


Dave, I really appreciate your input, but we are talking at cross purposes somewhere along the line - I am not sure where.

Firstly, just to ensure there is no confusion, I am not talking about *database* schemas, I am talking about *xml* schemas. From Wikipedia, "An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself."

Let's focus on 'form definitions'. What I call a 'form' is something that can be displayed on a user's screen, for data entry, data display, or both, containing text, input fields, checkboxes, buttons, etc, etc. I have devised an xml format to describe the form. When requested, the xml file is read in and sent to the client, which extracts the elements and renders them on the screen.

All form definitions are stored in the database. To ensure that they conform to the standard structure which the client is expecting, I have written an XML schema that can be used to validate the content.

The XML schema is stored in its sub-directory permanently. Once debugged, it will never be altered. It is the equivalent of source code, that is read and interpreted at execution time.

When a user selects a menu option, the form definition is read in from the database, parsed and validated by lxml using the schema, and if ok it will be sent to the client for rendering. Otherwise an exception will be raised.

Hope this makes more sense.

Frank


--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to