Re: [Gnue-dev] Object-Relational Mapping?

[Stanley A. Klein]

Reinhard -

Thanks for the reminder.  Appserver "objects" are not OO objects. The
mapping is relational to relational, and is straightforward.  You explained
that to me in our earlier discussion.


Stan Klein


At 06:51 AM 1/17/2003 -0500, Reinhard Mueller <address@hidden> wrote:

>Hello, Neil, Dan, Jason, and all,
>
>Am Fre, 2003-01-17 um 00.34 schrieb Neil Tiffin:
>> What is the current thought regarding end user (non-technical) customizat=
>ion?
>
>Just to make clear what we are (or at least I am) talking about when I
>talk about Appserver objects:
>
>* Appserver builds upon a straightforward relational database.
>Applications will probably not do die-hard normalization at any cost. We
>believe that data of business applications is mostly of relational
>nature.
>
>* Appserver basically provides access to the fields in the database,
>based on user permissions. Additionally to that, Appserver also presents
>calculated fields to the front end, which are fields that are not stored
>in the database, but calculated at runtime (however, they might be
>transparently cached in the database for performance reasons). They look
>to the frontend like "normal" fields.
>
>* Additionally, Appserver lets you define procedures that can be called
>automatically on specific events or manually.
>
>* We decided to name the combination of a database table, the calculated
>fields (with the code for the calculation) and the procedures an
>"object". Sorry. We didn't find a better word for it. When we say
>"object" we're not talking about die-hard OOP with inheritance or
>polyphormism. We just mean the combination of data and code.
>
>* We decided to name the fields on object level "properties" to
>distinguish them from the fields on database level.
>
>* The definition of how objects are built (that is, what properties an
>object has and what code the procedures consist of) is stored in system
>objects that are accessed by appserver at runtime. The user can simply
>add a new property to an object e.g. by creating a new object (read
>inserting a new row) of the class (read in the table) gnue_properties.
>(The names of the system objects are not yet fixed). Of course there can
>be a normal form for doing that, like inserting a new customer.
>
>* The definition of classes is merged from several module definitions,
>where each module has its own namespace. So we can make sure thinks like
>that the accounting module can introduce new properties to the customer
>class without affectin the function of the CRM module, and vice versa.
>
>* Although the Appserver objects are not objects in the sense of OOP,
>there is a language interface on it's way that maps appserver objects
>into Python objects. That language interface will let you do things in
>your python code like:
>list =3D session.find ("customer", "'zip' =3D 1234")
>for i in list:
>  print i.name
>  print i.street
>  print i.language.text
>  for c in i.contacts:
>    print c.name, c.phone
>
>I hope I have made things clear.
>