Live views are bi-directionally updatable. The first direction is from base data to the view: the base (source) data can be modified and the view will be automatically updated and then synchronized with the changed base data. That is what makes the views live. There is also the second, opposite direction: data can be changed directly in the view. This can be done programmatically (using the ViewRow), and it can also be done via data binding. Updating data directly in the view is especially common if you bind a GUI control, such as a grid, to a view. An example of updating data in a view via data binding can be seen in one of the first samples, Basic LiveLinq Binding, among others.
We call a view updatable if data can be modified directly in the view. This term only concerns the second direction of updating data. The first direction mentioned above, updating base data, is always possible without restrictions for any live views. So, when we say that a view is not updatable (is read-only), it does not mean that the data in the view cannot change. It can change to reflect changes in base data because every view in LiveLinq is live. It merely means that data cannot be changed directly in the view, you need to change base data if you want to modify it.
Not all live views are updatable, and even if the view as a whole is updatable, some properties of it may be read-only. These are properties that don't have direct correspondence to a property in the view's source data. Updating a view ultimately means updating that view's base data, that is, one of the view's sources, because the view itself is only virtual, does not have data of its own, shows (filtered and shaped) data of its sources. This is why a view field (property) can be updated only if it can be put into a direct correspondence with a property in the source. For example, in the following view
for c in customers where c.City == "London"
select new
{
c.City,
c.CompanyName,
FullName = c.FirstName + " " + c.LastName
}
City and CompanyName are updatable because they directly correspond to the City and CompanyName fields of the customers source. But FullName is not updatable, because there is no single field (property) in the source to which it corresponds, it is a combination of two source properties.
Any update of a view, which can be adding, deleting or modifying a view item, is performed by performing the corresponding operation, adding, deleting or modifying a single item in one of the view's sources. Although the effect is usually obvious and it usually does what is intended, it is important to know this simple rule, to understand it formally and exactly, because the result can sometimes be unexpected if you don't take this rule into account. For example, if you modify an item (or add a new one) in the above view so its City value is not "London", that item will disappear from the view.
The above rule stating that updating a view item is equivalent to updating an item of one of the view's sources, implies that only one of the view's sources can be updatable. A Join view has two sources, so we must determine which of them is updatable. By default, a join view is read-only. If you need to make one of its two parts updatable, use the extension method AsUpdatable(), for example:
for o in orders.AsUpdatable()
join c in customers on o.CustomerID equals c.CustomerID
select new
{
o.OrderDate,
o.Amount,
c.CompanyName
}
Here order data (date and amount) will be updatable and customer data (CustomerName) read-only.
To find out if a view is updatable, use the property View.IsReadOnly. The list of all properties of a view accessible to data binding and programmatic access, with full information including their updatability, can be obtained using the property ViewRowCollection.Properties.
Updating data directly in a view in code is done through a special class ViewRow, each view row representing a view item for programmatic access and data binding purposes. For details of using this class in code see reference documentation for ViewRowCollection and ViewRow.
