I'm working on a context extension of Verifiable Credentials and one of the properties in it will act as a metadata holder, with properties that can vary from one Credential document to another, and that are user set and hence relatively unpredictable (at least at #context level).
I was curious to find a way to define such a property in JSONLD?
The structure would be something like:
metadata: {
unknown1: '...',
unknown2: '...',
...
}
But my validator identifies unknown1 and unknown2 as unmapped properties, and that bothers me.
thanks
Ok so the route that was taken down was to stringify the value of property. Since it's now just a json string, there is no issue with expectability.
Related
I try to query a user including extended properties:
/users/xxx#xx.dk?$expand=properties
However I get following error:
Could not find a property named 'properties' on type 'microsoft.graph.user.
Is it possible in one request to get a user object with all of it's extended properties?
Best scenario would be something like following where I query for the departmentNumber from the extended properties with direct properties:
/users/xx#xx.dk?$select=companyName,officeLocation,departmentNumber&$expand=properties
This is because, as the message states, there is no property named properties.
How you retrieve custom properties depends on how they were created. There are two types: Open Extensions and Schema Extensions. Each is stored and behaves a little differently so you'll want to refer to the documentation I linked to for help determining which type you want to use.
My model consisted of the following example:
class Aggregate {
private SomeClassWithFields property;
}
Now I decided to introduce inheritance to SomeClassWithFields. This results in:
class Aggregate {
private AbstractBaseClass property;
}
The collection already contains a lot of documents. These documents do not contain a _class property inside the DB since they were stored before the inheritance was present.
Is there a way to tell Spring Data MongoDB to use SomeClassWithFields as the default implementation of AbstractBaseClass if no _class property is present?
The other solution would be to add the _class to all the existing documents with a script but this would take some time since we have a lot of documents.
I solved it by using an AbstractMongoEventListener
The AbstractMongoEventListener has an onAfterLoad method which I used to set the default _class value if none was present :) This method is called before any mapping from the DBObject to my domain model by spring so it works then.
Do note that I also needed to let spring data mongodb know the mappingBasePackage in order for it to be able to read an Aggregate before writing one. This can be done implementing the getMappingBasePackage method of the PreconfiguredAbstractMongoConfiguration class.
I have a simple use case that for the life of me I can't seem to figure out:
I have a model "Employee" that is based on the Loopback "User" model. My assumption is that the "id" of "Employee" would be the same as "User".
For the purpose of passing an Employee/User.id to an Angular.js route, I need to expose the Employee model's 'id' property in the RESTful response of the my Loopback API. Any idea on where or how to do this?
So far the Employee.id is profiled with the string "objectid"--which of course is not going to give me the correct user when I perform a Employee.find().
User.id is provided by LoopBack out-of-box. You can test this by adding a dummy user (via a boot script) and then browsing to localhost:3000/explorer to inspect the output of any GET request on the User object.
So, upon a more thorough review of the actual data in the Mongodb database it appears that '_id' in both User and Employee tables were always being populated with "objectid". This made me look at my models more closely. I compared them to the loopback-angular-admin's models--specifically their custom "user" model. What I noticed was that I had '"idInjection": true' on mine whereas the loopback-angular-admin project did not. So, I removed this property and VOILA: BSON/valid ObjectIds!
My models were generated with 'slc loopback:model'. This command line appears to add the '"idInjection":true' property to the models it generates. I don't know why this particular property would be problematic for Mongodb but the source of my original issue has been resolved.
I am building a custom package provider, and I am not sure what the query method is supposed to return.
Eg of a package provider:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/dpkg.rb
Found example of package provider, but no documentation of what each method is supposed to do.
Thanks!
The query method is called by the Puppet::Provider::Package base type. The properties method populates the property_hash using the query method:
# Look up the current status.
def properties
if #property_hash.empty?
#property_hash = query || {:ensure => :absent}
#property_hash[:ensure] = :absent if #property_hash.empty?
end
#property_hash.dup
end
In the rubydoc of Puppet::Provider it says the following about the property_hash:
Property hash - the important instance variable #property_hash contains all current state values for properties (it is lazily built).
It is important that these values are managed appropriately in the
methods {instances}, {prefetch}, and in methods that alters the
current state (those that change the lifecycle (creates, destroys), or
alters some value reflected backed by a property).
Thus, query should return a hash that reflects the current state of the package expressed in Puppet's package properties.
This is not documented AFAIK. I figured it out by reverse engineering.
Hope this helps. Good luck!
When I fetch models or collections from the server, I am not able to access properties of the model unless I stringify then re-parse. Presumably the models themselves have some extra overhead from backbone.js? Note that in the below code I can perform stringify/parse sequentially, which is supposed to give the same result as I started with. However, clearly I have killed off some superfluous info by performing these two steps because my model's properties are now exposed differently from before. Surely I do not need to go through these two steps to access my model properties, right?
Eg.
thismodel = /// assume this came from server fetch
alert(thismodel.name); // DOES NOT WORK - undefined
jsonmodel = JSON.stringify(thismodel);
var providerprefslistJSON = jQuery.parseJSON(jsonmodel);
alert(providerprefslistJSON.name); // WORKS
Backbone Model objects are not plain old JavaScript objects. They keep their attributes in an internal hash. To access the name attribute you can either do this:
alert(thismodel.attributes.name);
Or better yet use the get() method:
alert(thismodel.get("name"));
The reason it works when you convert the model to JSON and then back again is because JSON.stringify calls the toJSON() method, which creates a JSON string from the internal attributes hash, meaning when you parse that string you get a plain old JavaScript object - which is not the same as a Backbone Model object.
First, are you trying to access the property of the model or response?
From alert(thismodel.name) it would seem that you're going for a property of the model not the attribute. If you're looking for the model attribute then perhaps you want alert(this.model.get('name'))
If you're indeed going for model.name, then basically the problem may lie in how you're parsing the data. Say for example the JSON from your server is like this {'name':'Jimmy'}.
While the model.response the raw JSON sent has "Jimmy" namespaced under object.name, Backbone will automatically take that and turn it into a model attribute unless instructed otherwise (e.g. modelObj.attributes.name) at which point you'd use the get() function.
You should be able to access model data fairly simply if everything works.
E.g. Fetch
var model = new MyModel();
model.id = 1;
model.fetch({
success: function(model, response) {
console.log(model.get('name')); // The model name attribute
console.log(response.name); // The RAW response name property
}
});
Or maybe your server isn't sending the data back as JSON data. Is the server response content-type="application/json" ?
Some things to check.