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

[Reinhard Mueller]

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) customization?

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 = session.find ("customer", "'zip' = 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.

Thanks,
-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil