I'm having difficulty understanding the correct way to include validation information in a swagger file, when the validation logic can be dynamic (default, minValue, maxValue, etc.).
Consider the following example:
In a banking application, we a have a REST API for withdrawals. The withdrawal amount cannot be greater than the account value of the person taking the withdrawal. This value is going to depend on the context (Who's bank account we are withdrawing from) to get that maximum value. What is the correct/standard way to represent this information in a Swagger file?
The default/mininum/maximum/etc. values are static. OpenAPI/Swagger does not support parameter dependencies. You will need to document these restrictions verbally in the operation description and/or parameter description, and implement the logic yourself.
Related
I am doing some research on InfluxDB and found out that it uses an underlying Key-Value store for storage (like LevelDB, RocksDB, etc.).
I would like a mental model of what kind of keys are created for storing the time series data.
I am guessing something along the lines of "starting timestamp -> list of values...." but would like a more precise explanation about that.
InfluxDB works a little differently.
An InfluxDB database stores points. A point has four components: a measurement, a tagset, a fieldset, and a timestamp.
The measurement provides a way to associate related points that might have different tagsets or fieldsets. The tagset is a dictionary of key-value pairs to store metadata with a point. The fieldset is a set of typed scalar values—the data being recorded by the point.
The serialization format for points is defined by the [line protocol] (which includes additional examples and explanations if you’d like to read more detail). An example point from the specification helps to explain the terminology:
temperature,machine=unit42,type=assembly internal=32,external=100 1434055562000000035
The measurement is temperature.
The tagset is machine=unit42,type=assembly. The keys, machine and type, in the tagset are called tag keys. The values, unit42 and assembly, in the tagset are called tag values.
The fieldset is internal=32,external=100. The keys, internal and external, in the fieldset are called field keys. The values, 32 and 100, in the fieldset are called field values.
You can check out this post for the full explanation of the internals. https://www.influxdata.com/blog/influxdb-internals-101-part-one/
In OL2 feature id's were generated internally. In OL3 this doesn't seem to be the case since the id's are undefined. I have tried with WKT, JSON, and KML sources and none of them have id's assigned to features. Has the internal feature id been removed from OL3? If not what do I need to do to get the id's generated. I am requesting the id via:
feature.getId();
This is real problem for drag and drop since I don't have control over the files.
Cheers
No, OL3 does not generate any feature IDs.
When reading features, each Format may set the feature ID if it is defined according to the semantics of the format. For GeoJSON, it's the "id" member of the feature (not a property).
When creating new features, it's the responsibility of the application to set the features ID if necessary. Use the setId method of the feature. If using the Draw interaction, it's drawend event might be useful.
You should also note these facts about feature IDs in OL3:
No features with duplicate IDs may be in the same source. If you add a feature to a source where a feature with an equal ID exists, the new feature is ignored.
Feature IDs are compared as strings, so 1234 and "1234" are considered equal.
IDs are included when serializing features according to each Format's specification for feature identifiers.
How does work function Match in Acumatica?
For example I can't understand what following code does (this is code from coderepository.xml). Why in first case we don't mention table, but in second we mention table.
1. Search<InventoryItem.inventoryID,
Where<Match<Current<AccessInfo.userName>>>>
2. Search2<APInvoice.refNbr,
InnerJoin<Vendor, On<APInvoice.vendorID, Equal<Vendor.bAccountID>>>,
Where<APInvoice.docType, Equal<APInvoiceType.invoice>,
And<APInvoice.vendorID, Equal<Current<FAService.vendorID>>,
And<Match<Vendor, Current<AccessInfo.userName>>>>>
Match is used to filter records based on the restriction groups in place. Restriction groups are used to support row-level security; for example you can use that to restrict some users to specific products, specific customers or specific vendors. The internal implementation is quite complex, and relies on a bit mask field called GroupMask. Although it is used on a few specific entity types, it can be extended to work with custom entities.
There's a whole chapter on row-level security in the Acumatica User Guide, which should provide you with all the information you need on setting it up.
E. g. In Composition the element date has the data type dateTime.
<Composition xmlns="http://hl7.org/fhir">
...
<date value="[dateTime]"/><!-- 1..1 Composition editing time § -->
...
Is it with a Profile possible that the element date also adapts another data type, for instance the data type date?
See http://hl7.org/fhir/2015May/structuredefinition.html#6.17.5.2
Under the bullet "In practice..." the specification states "the list of types for an element must be the same or a subset of the list of types for the same element in the base structure".
So, no, new types may not be introduced. In general, a Profile (StructureDefinition) can only further restrict the use/content of a resource. It may not loosen the standard.
Chris is correct - the type cannot change and new types cannot be added. So if the specification says dateTime, you can't use "string" instead. However, in this specific circumstance, you can communicate "just date" within dateTime. And you can assert constraints against the type. So in theory, you could assert a length constraint of 10 characters on dateTime, essentially making it a date. As well, there's no requirement in FHIR that you store everything that's sent to you. So it's legitimate to throw away any time information that is sent to you (see http://hl7.org/fhir/2015May/updates.html for more information).
As a rule, stripping the time would be better than outright rejecting instances that contain a time. However, even that option is going to be seen as unexpected/undesirable by many communication partners.
assume a data structure Person used for a contact database. The fields of the structure should be configurable, so that users can add user defined fields to the structure and even change existing fields. So basically there should be a configuration file like
FieldNo FieldName DataType DefaultValue
0 Name String ""
1 Age Integer "0"
...
The program should then load this file, manage the dynamic data structure (dynamic not in a "change during runtime" way, but in a "user can change via configuration file" way) and allow easy and type-safe access to the data fields.
I have already implemented this, storing information about each data field in a static array and storing only the changed values in the objects.
My question: Is there any pattern describing that situation? I guess that I'm not the first one running into the problem of creating a user-adjustable class?
Thanks in advance. Tell me if the question is not clear enough.
I've had a quick look through "Patterns of Enterprise Application Architecture" by Martin Folwer and the Metadata Mapping pattern describes (at quick glance) what you are describing.
An excerpt...
"A Metadata Mapping allows developers to define the mappings in a simple tabular form, which can then be processed bygeneric code to carry out the details of reading, inserting and updating the data."
HTH
I suggest looking at the various Object-Relational pattern in Martin Fowler's Patterns of Enterprise Application Architecture available here. This is a list of patterns it covers here.
The best fit to your problem appears to be metadata mapping here. There are other patterns, Mapper, etc.
The normal way to handle this is for the class to have a list of user-defined records, each of which consists of list of user-defined fields. The configuration information forc this can easily be stored in a database table containing the a type id, field type etc, The actual data is then stored in a simple table with the data represented only as (objectid + field index)/string pairs - you convert the strings to and from the real type when you read or write the database.