I'm using Ignite Ui 16.1 igGrid with RESTDataSource.
Please, consider following configuration of one of the grid's columns:
{
headerText: $.i18n._("From"),
key: "start",
validation: true,
required: true,
dataType: "date",
editorType: "date",
format: "HH:mm",
editorOptions: {
validatorOptions: {
dateInputFormat: "HH:mm",
OnBlur: true,
OnChange: true
}
},
readOnly: false
}
When a new row is adding, in the payload of the post/create request start:"/Date(1470636037642)/" is sent to the server, which is parsed by the default MVC model binder as UTC date. This is absolutly in unison with Ignite Ui documentation that states all dates are sent in UTC.
Could you, please, point me out, how to configure this column, so a date with an offset to be sent to the server. I would like to know user's timezone. Thanks in advance!
You can add the timezone offset info manually in the transaction object.
features: [
{
name: "Updating",
editRowEnding: function(evt, ui) {
ui.values["offset"] = ui.values["CreateDate"].getTimezoneOffset();
}
}
]
If you use igGrid MVC Wrapper to deserialize the transaction log you will need to add an additional field (in this case named "offset") to your model.
Related
What is the proper way to configure apollo's cache normalization for a child array fields that do not have an ID of their own but are unique in the structure of their parent?
Let's say we have the following schema:
type Query {
clients: [Client!]!
}
type Client {
clientId: ID
name: String!
events: [Events!]!
}
type Events {
month: String!
year: Int!
day: Int!
clients: [Client!]!
}
At first I thought I can use multiple keyFields to achieve a unique identifier like this:
const createCache = () => new InMemoryCache({
typePolicies: {
Event: {
keyFields: ['year', 'month', 'name'],
},
},
});
There would never be more than 1 event per day so it's safe to say that the event is unique for a client based on date
But the created cache entries lack a clientId (in the cache key) so 2 events that are on the same date but for different clients cannot be distinguished
Is there a proper way to configure typePolicies for this relationship?
For example the key field can be set to use a subfield:
const cache = new InMemoryCache({
typePolicies: {
Book: {
keyFields: ["title", "author", ["name"]],
},
},
});
The Book type above uses a subfield as part of its primary key. The ["name"] item indicates that the name field of the previous field in the array (author) is part of the primary key. The Book's author field must be an object that includes a name field for this to be valid.
In my case I'd like to use a parent field as part of the primary key
If you can't add a unique event id, then the fallback is to disable normalization:
Objects that are not normalized are instead embedded within their parent object in the cache. You can't access these objects directly, but you can access them via their parent.
To do this you set keyFields to false:
const createCache = () => new InMemoryCache({
typePolicies: {
Event: {
keyFields: false
},
},
});
Essentially each Event object will be stored in the cache under its parent Client object.
In loopback framework, is there a way to avoid updates for few fields
Below code allows updates for all fields that is passed in the API request body.
async updateById(
#param.path.number('id') id: number,
#requestBody({
content: {
'application/json': {
schema: getModelSchemaRef(Todo, {partial: true}),
},
},
})
todo: Todo,
): Promise<void> {
await this.todoRepository.updateById(id, todo);
}
As far as I understand from your question, you want to update some part of the object in the database.
this.repo.updateById(id,objectYouWantToUpdate)
This is going to work perfectly, just send the data you want to update and not the whole object.
exclude key can help
schema: getModelSchemaRef(Todo, {partial: true, exclude: ['title']})
It is the first time that I use this version (4) for development and I have a problem with loopback and mongodb indexing.
Of the two ids that are inside the db loopback it does not collect any.
It's a problem of the API or DB?
Model [Loopback]
import { Entity, model, property } from '#loopback/repository';
#model()
export class Ad extends Entity {
#property({
type: 'number',
id: true,
required: true,
})
id: number;
<...>
constructor(data?: Partial<Ad>) {
super(data);
}
}
Data on Mongo:
{
"_id": {
"$oid": "5c0e9c7730146d2448746834"
},
"id": 110722,
"creation_date": 1492075600000,
"update_date": 1492075921000,
...
}
Response on loopback GET /ads
[{
"id": null,
"creation_date": 1492075600000,
"update_date": 1492075921000,
...
},...]
Hello from the LoopBack team :)
I don't see any obvious problem in the code snippets you posted. What happens when you change id's type from number to string? Will it fix the problem?
Most likely, you have found a bug in LoopBack 4. Please report it via GitHub: https://github.com/strongloop/loopback-next/issues
I fixed the same issue by changing the id=String. Mongodb id contains both string and number. So, if you change the type of id=string (Model) the issue will be fixed.
I have JSON coming from the server which looks like:
data: {
user: {
address: {
id: "id",
city: "city",
street: "street",
.......
}
name: "name",
......
}
authentication-token: {
token: "token",
id: "id"
}
}
The idea is to store this two models (user, authentication-token) in ember store under the same names. When I gat the above mentioned response from a server, model user is saved successfully, but model authentication-token does not get saved to the store at all. When I log the data (in the adapter) before the data is passed to serializer I see that JSON has a structure which Ember-Data expects. I don't know whether the problem is that Ember-Data cannot handle two models in success at one time, and then save it to the corresponding models, or something else. Ideas?
Now it all makes sense to me. Of course, this was the problem in your last question. Anyway, ember-data's RESTAdapter can't handle this. If you're requesting a singular resource user it expects at most this user as a singular answer. Any other resource that may be "side-loaded" has to be an array. The requested singular user can either be a record under the user key or the first entry in an array unter the users key. Everything else (except meta data) has to be plural.
In case you're requesting a plural resource users, the main response must be under the users key, any sideloaded users that aren't part of the response prfixed with _ under the _users key.
For your example all this means that your json must be formatted like this:
data: {
user: {
address: {
id: "id",
city: "city",
street: "street",
.......
}
name: "name",
......
}
authentication-tokens: [{
token: "token",
id: "id"
}]
}
If you can't change your server, you'd have to configure the RESTAdapter to normalize the JSON data through normalize of the Serializer.
What I'm Trying:
Persist a new record but for some reason the request payload is empty even though the record has data.
Here's a fiddle: http://jsfiddle.net/brancusi/m8VrB/16/
(Disregard the firebase, it's just there so we can inspect the request payload on save.)
Explanation:
You will notice that when you save the record, the request payload is empty.
Ideally the request payload would look something like this:
{
"inventory": {
"entry_time": "2014-02-05",
"client_id": 1,
"user_id": 1,
"product_stock_levels": [
{
"product_id": 1,
"quantity": 2
},
{
"product_id": 2,
"quantity": 0
},
{
"product_id": 3,
"quantity": 8
}
]
}
}
Notes:
This only seems to be a problem when it's a new record. Updating existing records send the correct payload.
You are expecting ember data to embed relationships in a model on save as default. This is not the default behavior.
You could define relationships as being embedded per model. But there is no support for embedded record feature anymore as stated here: https://github.com/emberjs/data/blob/master/TRANSITION.md I am not sure if basic embedded record features still work with latest version of ember data. But you define a record as embedded like this:
App.InventorySerializer = DS.ActiveModelSerializer.extend(DS.EmbeddedRecordsMixin, {
attrs: {
productStockLevels: {embedded: 'always'}
}
});
Because core team stopped support for this embedded records feature and it is very basic I would recommend you to use EmbbededAdapter or EmbeddedMixin if you need support for embedded records. You find them here: https://github.com/pixelhandler/ember-data-extensions
But as Ember Data EmbeddedAdapter is not stable yet. Perhaps you should consider not to embedded records to reduce complexity if you are flexible in defining the api.