The documentation mentions that extended properties are a finite resource in a user's mailbox, and exceeding this limit will result in unexpected errors when trying to create new properties.
It is not mentioned explicitly anywhere that I could if item customProperties, as written to through the Office.js client, has the same limitation. Does it?
We plan to optionally write a small amount of data to item customProperties if the user modifies inputs exposed in our Add-in Taskpane in the Outlook client. These properties will later be read by a server consuming changed events through the events delta API.
Will we eventually run into issues with this approach if we don't implement some sort of "garbage collection" of no longer used customProperties?
Item custom Properties are extended properties https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcext/4cf1da5e-c68e-433e-a97e-c45625483481?redirectedfrom=MSDN
So you have one extended property and then the value is a Json Key pair so one Extended property provides multiple custom properties (up to the limitation of the size of the Extended property)
Even if you don't want to use Item Custom properties its a good idea to follow the same approach eg create one extended property for your app and then store what ever combination of property values you need as a JSON structure in the value on the property. Its not a good idea to have your application creating random/multiple custom properties as you will easily exhaust them/create a mess and there is no advantage in doing it that way.
Related
This is a simple question.
Start a multidevice App, place a TDateEdit and DBTable with a field containing TdateTime data. Then use LiveBinding designer link the data source field to TDateEdit.DateTime property. However, this link is unidirectional , The control DateEdit can accept the data from the Datasource, but cannot update the changes to the datasource. How to change the link to bidreiction???
There may be some things that are not clearly understood.
Normally a LiveBindings link will be bidirectional - so if you setup two TDateEdits and bind them together changing one should change the other, irrespective of which one you change.
It seems that what you are hoping is that changing the TField will update the data in the database table.
That's not typically how the Data Access components in Delphi work.
The TField is part of a TDataSet. The TDataSet has a Post method to write changes to the underlying data store, if that's supported.
The Data Access components are extremely powerrful and can cope with lots of different scenarios, and allow you to extended capabilities throguh exposed events as well as subclassing the components.
If you want to update your underlying data store you need to have a writeable TDataSet and you need to call Post on it to write.
I suggest you start off with some of the videos in Enbarcadero's YouTube channel about how to use the data acecss components. It's not difficult to do but beyond the scope of an answer here.
If you use the LiveBindings Wizard to hook the DateEdit with a field, it will hook it up bi-diretionally to a "virtual" SelectedDateTime property of the DateEdit. That property doesn't really exist in the TDateEdit but is used by the LiveBindings to map the separate Date and Time properties of the DateEdit.
https://facebook.github.io/relay/graphql/objectidentification.htm is very clear around what Node is and how it behaves, but it doesn't specify which objects must implement it, or what the consequences are if your object doesn't implement it. Is there a set of features that don't work? Are such objects completely ignored? Not all objects in the existing spec (e.g. pageInfo) implement it, so it's clearly not universally required, but pageInfo is somewhat of a special case.
Another way of thinking about the Node interface is that objects that implement it are refetchable. Refetchability effectively means that an object has an ID that I can use to identify the object and retrieve it; by convention, these IDs will usually be opaque, but will contain type information and an identifier within that type (eg. a Base-64 encoding of a string like "Account:1234").
Relay will leverage refetchability in two ways:
Under a process known as "diffing", if you already have some data for an object identified by ID QWNjb3VudDoxMjM0 (say, the name and address fields), and you then navigate to a view where we show some additional fields (location, createdAt) then Relay can make a minimal query that "refetches" the node but only requests the missing fields.
Relatedly, Relay will diff connections and will make use of the Node interface to fill in missing data on those (example: through some combination of navigation you might have full information for some items in a view, but need to fill in location for some items within the range, or you might modify an item in a connection via a mutation). So, in basic pagination, Relay will often end up making a first + after query to extend a connection, but if you inspect its network traffic in a real app you will also see that it makes node queries for items within connections.
So yes, you're right that pageInfo doesn't implement Node, and it wouldn't really make sense for it to do so.
I think the answer is no, but the question has been put to me so I'd like to confirm. My understanding is that any custom XBL control that I create for use in Form Builder can have one and only one value. Is this correct?
I have always assumed this because the control name is then used in the data instance as the name of the node which contains the the value.
This question comes from the desire to have reusable components with multiple values, for example, an Address control so that addresses can be recorded consistently and the same set of fields does not need to be added many times. Orbeon does have some support for this in the form of Section Templates but because the control names stay the same in each instance of a Section Template this does not work well with our design.
The best idea I've had is that a custom control which records multiple values could encode all the values into a single text string for example in JSON. Of course, this is not ideal.
Are there any other options?
It is possible for controls to have multiple values. When that happens the values are typically stored in nested elements. I.e. a control could bound to an element <address>, and could create nested elements <street>, <city>,<country>, etc to store the different parts of the address.
In practice, you can look at how this is done in the Image Annotation annotation control (see wpaint.xbl), which creates nested elements <image> and <annotation>, leveraging the xxbl:mirror="true" functionality.
I have a navigation property, which I added a custom validator to.
The validator triggers fine when saving the entity. However it does not trigger when adding/removing entities from the navigation property.
Should I subscribe to propertyChanged event, or is there another way to handle this ?
Also, why is there not a propertyChanged event per property instead of having to subscribe to any properties change ?
There are two kinds of navigation properties, scalar and nonscalar. A scalar property is something like 'Order.Customer' where an order has a single customer associated with it. Setting or changing the customer in this case will fire the entityAspect.propertyChanged event.
For a nonscalar property like say 'Customer.Orders', accessing the property returns an array of orders associated with the customer.
This is always the same array. Orders can be added or removed from it, but the returned array itself is always the same. Because the array itself is never changed a property change is NOT fired for these operations.
However you CAN watch the array itself for changes, see the arrayChanged event
in the breeze Api docs.
As for why there is no separate event that you can register to fire only when a specific property is changed, the reason is that the current mechanism supports your ability to do this while at the same time allowing for those use cases where you want to see 'all' of the changes to an entity without having to register what could potentially be tens of thousand of events.
Remember entity property level events, if they existed, would have to be registered on as many entities as are in your cache (100's or 1000's) times the number of properties on your entities (5-50).
Most of what is described here is fairly standard for entity change tracking in a number of environments across a variety of programming languages. We didn't try to reinvent the idea, but simply reimplemented a pretty common standard.
Is it possible to query an OData collection filtering by the updated metadata field? The case for that would be to get a list of updates since the last check.
I've tried http://odata.netflix.com/v1/Catalog/People?$filter=updated%20eq%202011-05-15T21:45:31Z, but it gives me "No property 'updated' exists in type 'Netflix.Catalog.Person' at position 0". Is there another way I can do this or reference the updated property in a filter statement?
The updated element in the ATOM feed/entry representation may or may not contain actual data. Some services actually do store the real updated timestamp there, but some don't. Since the element is required to be present in all entries by the ATOM format, services which don't have the data to use there usually put some arbitrary timestamp as the value (by default WCF Data Services uses DateTime.Now for the updated field, which is what netflix service does as well).
The $filter can only reference real properties on a given entity. So if the service does have a property which contains the data backing the updated element you would need to find out the name of such property (in the $metadata for example) and then use that. If the service does not have a property like that (for example the netflix service doesn't), then there's no way to filter based on last updated timestamp, as there's no such thing in the underlying data store (the updated element is effectively a fake).
Also note that if you ask for JSON payload the updated element doesn't exist there and so only the real properties are present. Any query operators in the URL work only on the real properties.