Relational schemas or class based development can constrain more than
data, they can also constrain free flow development.

As mumps developers we also understand the pit falls of schema free
databases, something else the "new kids" have to experience firsthand.

In fact what we need is not a "schema free" database, but a "free flow
schema" database. A free flow schema that promotes free flow
development, call it an adaptive or semantic schema. Add
to that a layer of abstraction that overcomes the pit falls of raw
global development.

I see this abstraction not as classed based development but as object
based development in a similar way that JavaScript objects are freely
written. These objects auto inherit persistent functionality and
constructors to serialise and de-serialise object data such as HTML
forms, JSON and XML.

In "design mode" the developer can design and code freely. Once this
stage is completed constraints can then be optionally applied to the
semantic schema. In "run time mode" these  constraints assure the
quality of data and help protect against security issues such as data
injection.

The semantic schema is constructed with information gathered either by
the compiler or by the data engine during "design mode". Consider the
following example...

FooBar.Person
{
  Save()
  {
    Set person=FooBar.Person(%session("person"))
    Set person.Updated=Lib.Dates.Now()
    Set person.Sex=
$Select(Person.Sex="Male":"M",Person.Sex="Female":"F",1:"U")
    Set status=person.save()
    Write status
  }
  ToJSON()
  {
    Set person=FooBar.Person.Open(%session("person.id"))
    Set person.Age=Lib.Dates.Age(person.dob)  //this could be moved
into the semantic schema
    person.Salary.Hide()  //hide this information from general
requests
    Write person.ToJSON()
  }

First off lets assume that EWD is being used as the web engine,
%session will therefore compile down to $$getSessionValue^%zewdAPI. On
an EWD page an action will call FooBar.Person.Save()
which will post the blob of person data, this could be html form data,
JSON or XML. The constructor recognises the type and constructs a run
time object. We can manipulate that object
before saving it to the database. The save() method abstracts all the
global saves, transactions and error handling.

At compilation time the compiler doesn't know much about the Person
object. But once the code is executed during "design mode" the data
engine can profile the person object and add
information to the semantic schema. This allows the developer to
change the form object without making changes up stream.

Whilst the semantic schema could be used to drive a SQL engine such as
GT.m's PIP engine I see a much more simple "for each object where..."
syntax. This could be used to spin through data
or output data as a certain format type. For example...

FooBar.Person
{
  BySurnameAsArray(surname) As JSArray
  {
    for each person in FooBar.Person where person.surname=surname
    {
      select person.surname as "Surname", person.forename as
"Forename", person.address.postcode as "Post Code"  //similar to a
result set
    }
  }
  BySurnameAsJson(surname) As JSON
  {
    for each person in FooBar.Person where person.surname=surname
    {
      select person  //this version outputs a collection of person
objects, more sophisticated than a result set
    }
  }

1. Adaptive indexing
2. Automatic detection and adaptive indexing of object relationships
(completely do away with joins in queries)
3. Integrated RAD studio with features such as auto complete of
semantic objects and inteligent warnings
4. The ability to project class based languages into semantic objects,
such as Cache, C# and Java. For instance Cache data could be injected
into GT.m. Or in reverse mumps could take
advantage of the powerful libraries in .NET and Java by projecting
semantic objects as C# / Java data proxy objects.

The bottom line is that its easy to see how Mumps already has the
flexibility and more importantly the speed to handle this type of
functionality. Trying to achieve the same functionality within
relational databases is just one more layer of complexity to add to
the object-relational impedance. Which just adds up to sluggish,
costly and difficult to scale applications.

Whilst Cache could provide a platform for this functionality it will
never fit into the low cost web application model.

Thankfully GT.m is open source and is just begging for this type of
solution to be developed for it. If a non-scalable solution such as
ruby on rails can go mainstream then what could a powerful and
scalable GT.m / EWD / Extended Mumps solution do for the web
development industry?

Mumps is not dead!

Sean.

On 16 Aug, 14:03, rtweed <rob.tw...@gmail.com> wrote: