[GNUe-dev] Proposal for special property types in AppServer

[Reinhard Mueller]

Hi,

I've had some ideas about features in AppServer that could make things
easier for application developers. These things are basically special
property types.

Basically, we define classes and properties in appserver, where as of
now every class maps 1:1 to a database table and every property maps 1:1
to a column in that table.

The idea would now be to introduce more properties that do not map 1:1
to a column, but are provided by appserver from a more indirect source.

There are 3 basic kinds of such properties I have in mind now:


1. Indirect properties:
-----------------------

If we have a class, say an invoice, with a property "customer" that
references another object that has properties "name" and "street", we
could define that accessing the property "customer.name" makes appserver
silently generate a join between the invoice table and the customer
table, and return the name of the invoice's customer.

This kind of property would unfold even more power if we allowed to use
it in conditions, e.g. query for all invoices where the customer's zip
is "6890".

Of course we would not limit that to one step, so reading
"customer.country.name" would in fact generate a query like
"SELECT country.name FROM invoice, customer, country WHERE
invoice.customer = customer.gnue_id AND customer.country =
country.gnue_id;"

(I'm not using fully qualified names like foo_bar here for the sake of
readability)

Of course these properties would be read only.


2. Formula properties
---------------------

Appserver could also support access to properties with psuedo-names like
"price*quantity". Maybe we would even let the user define new names for
these formula properties (e.g. "total").

What appserver would do then would be pass that formula to the backend
in the generated SQL. Eventually appserver could provide a way to do the
calculation if the backend can't (e.g. if the backend isn't SQL).

This would unfold most of it's power if we made it possible to use
fields from outside the current table in the formula, things like
quantity * item.price * (1 - customer.discount / 100)
[where item and customer would be reference properties] or
sum (items.total, items, item.invoice = gnue_id)
[absolutely not sure abot this syntax, but you might get the point]

The special thing about all these formula properties would be that
appserver would try to pass the calculation to the SQL backend, which
would improve performance against the third alternative:


3. Calculated properties:
-------------------------

They would be probably much easier to implement than formula properties:
They would just call a procedure (e.g. accessing a propert "total" would
silently call a procedure "gettotal") that has no parameters and a
single return value.
This is the most flexible way, you can do everything here what you can
do in python.
The downside is that appserver does all the calculations, and therefore
has to request all necessary data from the SQL backend (even if it is,
for example, 500 invoice items to calculate the total invoice amount).

Also, if such a property is used in a condition, appserver would request
all records not excluded otherwise from the SQL backend, even if only a
small part of them would fulfill the condition.

So this way is best for flexibility and worst for performance.


I'd like to get input on these thoughts.

Thanks,
-- 
Reinhard Mueller
GNU Enterprise project
http://www.gnue.org
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
No army can stop an idea whose time has come.
        -- Victor Hugo, 1802-1885

signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil