In GeneXus 15 there are some interesting improvements to data modelling and to the power of transactions.In particular, we can define a transaction which has an associated Data Provider, which allows for some basic functions and specializations of said transaction, such as Dynamic Transactions.
The background impact of this improvement is that development becomes more oriented towards the Transaction/Attribute paradigm, which makes it much easier for a GeneXus Developer, since this is a paradigm which he knows and controls.
An example application of those “basic functions”: when one defines that a transaction will have an associated Data Provider (Data Provider property) one can do interesting things, such as populate the transaction’s data at the moment of creation/reorganization from that Data Provider (among other things). This way, “loading procedures” are not necessary and one does not need to worry about their execution.
An example of “specialization” (dynamic transactions): A transaction can be defined to be a “view” of others (it ends up as a VIEW in SQL) using these properties and defining the Data Provider that “populates” it. For example, one can therefore end up having only one transaction as a UNION of different structures and managing it as a single transaction.
The applications with this kind of definitions are endless. The following (very small) example shows how we can consolidate the information from different transactions in one and later use it as a whole. By “use it” it is understood that one can use For each commands, DPs, or anything else on these dynamic transactions, and even use them as foreign keys in other transactions.
A GeneXus application “Sales” has Products, Services, and Purchase Orders (PO), which has two sublevels: the Products sold and the Services sold:
Note that the example is very simplified, as Product and Service in reality both have attributes specific to each entity. A product has a color, measurements, etc. while a Service has a duration, a cost, etc.
What we can do is define a Dynamic Transaction (ProductAndService) which has an associated DP that “loads” the data to the structures of Service and Product (red arrows). This means that it’s a VIEW which implements the UNION of the two transactions (this is why “loads” is in quotation marks, since it’s not an actual load that would create redundant data).
Once this is defined, in the PO transaction we can include only one sublevel which has the keys of ProductAndService as foreign keys.
In the same way, we can create a Webpanel which accesses this “table” by directly mentioning the attributes, and we can display that transaction as a service. We can even implement the Insert, Update, and Delete methods on the dynamic transaction, as mentioned in Dynamic Transactions that update data
The example is avaliable to be executed here. In particular the ProductAndServices transaction is the one that ends up being a UNION between Products and Services, and it’s a sublevel of the PO transaction.
The KB can be found here if one wants to see how the objects are defined, their properties, etc.
The most relevant part
The ProductAndService transaction has an associated Data Provider and is used to retrieve data:
The Data Provider created by default was modified to define where the data is obtained from:
ProductAndServiceCollection{
ProductAndService
{
ProductAndServiceType = !"P"
ProductAndServiceId = ProductId
ProductAndServiceName = ProductName
}
ProductAndService
{
ProductAndServiceType = !"S"
ProductAndServiceId = ServiceId
ProductAndServiceName = ServiceName
}
}
Note: In the dynamic transaction (ProductAndService ), as the key of a product can be the same as the key of a service, an attribute Type (P or S) was added as part of the primary key.
In the example the concept of “Data provider to initialize data in a transaction” is also used in the transactions Product and Service.