Re: THe OverRelational Manifesto (ORM)
Date: 6 Apr 2006 08:49:26 -0700
Message-ID: <1144338566.009972.191850_at_e56g2000cwe.googlegroups.com>
Thank you. This question seems to be good and I have to take some time to answer it. But can I answer you? My question is not new for me because I asked some person who knows D well before but nobody can answer me. In this question I propose my interlocutors to compare ORM and TTM.
Little preliminaries. In this example I'm possible inaccurate and I omit very important subjects (keys for example). And it is big enough.
The long entry.
Goods are shipped from warehouses. We have to know how many goods was
shipped from some warehouse.
//We create type to describe warehouse
CREATE CLASS WAREHOUSE
{
Name String;
}
GO
//We create type to describe shipment
CREATE CLASS SHIPMENT
{
//--
No INTEGER;
WareFrom WAREHOUSE;
//--it was information from header of invoice
ShipmentItems SET OF //-- and this is a set of invoice lines
{
Article STRING;
Pieces INTEGER;
}
}
GO
//information of invoice lines implemented as stored
ALTER CLASS SHIPMENT IMPLEMENT ShipmentItems AS STORED;
GO
//O, I've forgotten about constructors,
ALTER CLASS WAREHOUSE
ADD WAREHOUSE(InitialName STRING)
IMPLIMENT AS
BEGIN
Name = InitialName;
END
GO
//slightly other way
ALTER CLASS SHIPMENT
ADD SHIPMENT(InitialNo INTEGER, InitialWareFrom WAREHOUSE);
GO
ALTER CLASS SHIPMENT
IMPLIMENT SHIPMENT(InitialNo INTEGER, InitialWareFrom WAREHOUSE) AS
BEGIN
No = InitialNo;
Warehouse = InitialWarehouse;
END
GO
//Now I can create a number of new objects in our DB
//create object to describe some warehouse
NEW WAREHOUSE("SomeWarehouse");
//NEW in non-pocedural commands, so I can write...
GO
//create object to describe some shipment...
NEW SHIPPMENT(1, Object(Warehouse<Name = "SomeWarehouse">));
GO
//...and edit this object
INSERT SHIPMENT<No = 1>.ShipmentItems VALUES ("SomeArticle", 100);
GO
...
Now we can create relational variable openly (i mean that we already have a lot of relational variables created implicitly; i call them R-variables) and implement it as variable which contain value calculated on values contained in that, created implicitly R-variables. One of these R-variables we implicitly created before is R-variable named as 'Shipment'. In this R-variable scalar attributes named as 'ShipmentItems.Article', 'ShipmentItems.Pieces', 'WareFrom' (and possible other ones) exist.
CREATE ShippedGoods AS SET OF
{
Article STRING;
Pieces INTEGER
}
IMPLEMENT AS
SELECT ShipmentItems.Article,Sum(ShipmentItems.Pieces)
FROM Shipment
WHERE WareFrom<Name = SomeName>
GROUP BY ShipmentItems.Article;
GO
Really variable ShippedGoods is full analogue of view.
So in class SALE information about shipped goods is calculated.
And after the definition of new class SALE we have to do NOTHING on early defines view ShippedGoods to get information both about real shipments and about shipments for sales.
In other words in R-variables the information is collected both from components defined as stored and from components defined as calculated. A lot of subtypes of type SHIPMENT can exist in system and in each subtype the component ShippedItems can be re-implemented in different ways - we must know nothing about it but every time we will get correct information in early defines view ShippedGoods (of course if implementation is correct).
Is it possible in D?
Anyway I answer you question in sometime. Received on Thu Apr 06 2006 - 17:49:26 CEST