Modifying a read only element causes an exception. Retrieving elements from the TX, or directly from the ElementMap returns a clone, so nothing changes there. But elements returned by a query will have their readOnly flag set, thus if these are modified, then they need to be cloned first.
New:
- needsCommit() -> return true if objects or commands are registered
- hasResource()
- hasOrder()
- hasActivity()
Changes:
- When tx.add(), update() or remove() is called, then get*Template(), or get*By() check the internal cache and thus e.g. a new resource is immediately available.
- the has*()-methods also check the internal cache, thus the need to get the underlying maps should now no longe be required in normal TX use.
Now execution is always performed asynchronously for each Action and an
Activity should be added to the ExecutionHandler by calling
.addForExecution(), so that it is executed later even if an action
couldn't be executed to it being reserved (for instance).
If a column definition exists as follows:
<Parameter Id="minQuantity" Name="Min Quantity" Type="String"
Interpretation="Resource-Ref" Uom="Storage"
Value="$search:parent:Bags/parameters/minQuantity" />
Then a search is done by looking on this element, and all "parent"
elements where the parent relation is defined by the parameter with the
id "parent". The first instance of the Parameter "minQuantity" is used
as the value for the report.
Create a Report as follows:
<Resource Id="stockReport" Name="Stock Report" Type="Report">
<ParameterBag Id="parameters" Name="parameters" Type="Parameters">
<Parameter Id="objectType" Name="Object Type" Type="String"
Interpretation="Resource-Ref" Uom="Slot" Value="Slot" />
</ParameterBag>
<ParameterBag Id="columns" Name="Display Columns" Type="Display">
<Parameter Id="location" Name="Location" Type="String"
Interpretation="Resource-Ref" Uom="Location" Value="$name" />
<Parameter Id="storage" Name="Storage" Type="String"
Interpretation="Resource-Ref" Uom="Storage" Value="$name" />
<Parameter Id="section" Name="Section" Type="String"
Interpretation="Resource-Ref" Uom="Section" Value="$name" />
<Parameter Id="slot" Name="Slot" Type="String"
Interpretation="Resource-Ref" Uom="Slot" Value="$name" />
<Parameter Id="product" Name="Product" Type="String"
Interpretation="Resource-Ref" Uom="Product" Value="$name" />
<Parameter Id="quantity" Name="Quantity" Type="String"
Interpretation="Resource-Ref" Uom="Slot"
Value="Bags/parameters/quantity" />
<Parameter Id="maxQuantity" Name="Quantity" Type="String"
Interpretation="Resource-Ref" Uom="Slot"
Value="Bags/parameters/maxQuantity" />
</ParameterBag>
<ParameterBag Id="joins" Name="Joins" Type="Joins">
<Parameter Id="Product" Name="Product" Type="String"
Interpretation="Resource-Ref" Uom="Product" Value="Slot" />
<Parameter Id="Section" Name="Section" Type="String"
Interpretation="Resource-Ref" Uom="Section" Value="Slot" />
<Parameter Id="Storage" Name="Storage" Type="String"
Interpretation="Resource-Ref" Uom="Storage" Value="Section" />
<Parameter Id="Location" Name="Location" Type="String"
Interpretation="Resource-Ref" Uom="Location" Value="Storage" />
</ParameterBag>
</Resource>
This creates a report for objects of type Slot, where a Join is done on
multiple objects:
Slot
-> Product
-> Section
-> Storage
-> Location
Thus the columns can then be fetched from different joing objects. The
joing is done by searching for a Parameter on the joined object on the
ParameterBag "relations". See the example XML on how this is done.
Or ask eitch@eitchnet.ch to write a proper documentation =))
Filtering is missing, and will be added later
This is required because in certain instances it is important to lock
the object before retrieving it, otherwise if, for instance in
execution, we would need to fetch, lock and re-fetch to be sure we have
the latest object.
In moste of the Update*Commands this is not important as we perform a
list commit wins, where the client wants their version to be persisted.
Later a optimistic locking can be performed in that the given version
must be the latest, otherwise an exception would be thrown
Should a command be undone, then some commands performed an undo,
although they didn't perform their work, this led to an inconsistent
data model. I.e. AddResourceCommand would fail because the resource
already existed and an undo would lead to the existing object being
removed