Is indexing via view with respect to an inner property of inner object inside a document is more expensive of a property of the document itself.
Say for example if have a document A as follows:
{
"person":
{
"id":1234345,
"name":"eyal"
},
//... more properties of document A
}
and I want to run a view according to id of person.
Does it more expensive (the indexing etc) than the following document:
{
"id":1234345,
"name":"eyal",
//... more properties of document A
}
Thank u in advance
No, There are not speed differences between the two methods.
Related
I want to force a document to classify against a particular layout on Hyperscience - is this possible? I can use the uuid, layout_uuid, layout_version_uuid, along with other metadata. I also want to include the pages belonging to the document if it has been classified already.
I’ve already set up the custom code block to perform this function as below:
def force_classification(submission: Any) -> Any:
***insert code here***
return submission
cct_force_classification = CodeBlock(
reference_name='force_classification',
code=force_classification,
code_input={'submission': previous_block.output('submission')},
title='Force Classification',
description='Force Classification',
)
Reading the SDK docs, I didn't see a clear way to do this. I'm wondering if this is just not possible?
Yes, this is possible! However, there are some limitations. You are able to use a custom code block to specify the layout that a document must be classified against if it has already been classified, as long as the layout that you’re forcing classification against is a semi-structured layout.
new_documents = []
for document in submission.get('documents', []):
if document['layout_uuid'] == 'layout_uuid[1]':
new_document = {
'uuid': document['id'],
'layout_version_uuid': 'layout_version_uuid[2]',
'layout_uuid': 'layout_uuid[1]',
'pages': [{
'submission_page_id': page['id'],
'page_number': page['submission_page_number'],
'classification_type': page['classification_type'],
} for page in document.get('pages', [])],
'metadata': {},
}
new_documents.append(new_document)
return {'submission': submission, 'new_documents': new_documents}
Note that, here, layout_uuid[1] refers to an existing document, and 2 corresponds to the metadata of the other layout you want to force classification against.
Keep in mind that this is still superficial (client side) and will not reflect in the Hyperscience db until you sync this new document back.
I wrote a class for my project like this using typescript and react.
class myImage extends Image {
oriHeight: number;
}
After I uploaded two images I have an array named 'results' which is full of objects with type myImage.
[myImage, myImage]
When I click it in browser, I could see the data of oriHeight of each element.
Then I try to use results.map() method to traverse all the elements in that array.
results.map((result: myImage) => {
console.log(result);
var tmp = result.oriHeight;
console.log(tmp);
})
However, the output of result is no longer an object but an img tag (because the type of Image is a HTMLElement) which makes the data of result unreadable. So the output of every tmp is undefined.
I am confused about that. Why the myImage object will become an img tag when I want to traverse it? I hope someone could help me with that. Really appreciate it.
I bet your data is actually fine. When you console log an html element, the chrome console displays it as an html tag instead of the javascript object.
Update: It's generally a bad practice to add your own properties to DOM elements because they're harder to debug and you risk them being overwritten by future browser properties. Instead, you could create a javascript object that contains both the image and your custom property. Here's an example interface definition:
interface MyImage {
imageEl: HTMLImageElement;
oriHeight: number;
}
I know the attached function doesn't guarantee that properties will be loaded.
Right now, I've been using a computed Function that depends on properties but it's very clunky.
I've also used async but I find it to be inconsistent and arbitrary (just picking a random time to delay by).
I can't find anything about the correct way to deal with this problem.
You can use observers.
for example you
properties:{
someproperty:{type:Number,observer:'change'}
},
change:function(){
//this function called when the property changes.
}
for more information look at https://www.polymer-project.org/1.0/docs/devguide/properties.html
In addition to Alon's answer: if you want to observe several properties, then you can use something like this:
properties:{
someproperty1:{
type: Number,
}
someProperty2:{
type: Number,
}
},
observers: ['change(someproperty1, someproperty2)'],
change:function(property1, property2){
//this function called when the property changes.
},
Note, when using single observers, they will fire in the order they are set. So if someproperty1 and someproperty2 had specific observers binded to them, then the method that someproperty1 had will be executed first.
To read more about observers, read here:
https://www.polymer-project.org/1.0/docs/devguide/observers#multi-property-observers
I need too filter the iNotes calendar control in extlib. When I look in the examples in the extlib application I can see that it is suppose to be connected to a xecalendarJsonLegacyService.
The problem I find with this service is that I can't filter the content based on category or search as with the other view services.
I need to create different calendars/json data based on a search or category in a view.
I have looked at some of the other services but not sure if it is possible to use them instead.
If you have any ideas for how I should create my filter, please respond.
I have attached pictures below showing both the jsonservice and the calendarcontrol.
This is what the json data look like in the xsCalendarJsonLegacyService
{
"#timestamp":"20120311T171603",
"#toplevelentries":"3",
"viewentry":
[
{
"#unid":"37F0330979C04AF2C12579BE004F5629",
"#noteid":"32E1A",
"#position":"1",
"#read":"true",
"#siblings":"3",
"entrydata":
[
{
"#columnnumber":"0",
"#name":"$134",
"datetime":
{
"0":"20120314T100000"
}
},
{
"#columnnumber":"1",
"#name":"$149",
"number":
{
"0":119
}
}, etc...
You could implement your own REST service (or extension to existing one) in an extension library, but I guess you are looking for something easier.
Sorry no code, but maybe (and hopefully) an answer.
Have you looked at the xc:CalendarStoreCustomRestService custom control inside the Xpages Extension Library demo? It looks like they connected the calendar control with a normal JSON view store and that supports search en keys.
I found code you could use but you will have to extend the custom control. I think it is a new component that is not yet included as a xe: component inside the Extension Library.
This is how you use the control:
<xc:CalendarStoreCustomRestService id="cc4ccCalendarStoreCustomRestService"
storeComponentId="notesCalendarStore1" databaseName="#{sessionScope.databaseName}"
viewName="($Calendar)">
</xc:CalendarStoreCustomRestService>
This is your calendar component, it uses the above storeComponentId.
<xe:calendarView id="calendarView1" jsId="cview1"
summarize="false"
type="#{javascript: null == viewScope.calendarType? 'M' : viewScope.calendarType }"
storeComponentId="notesCalendarStore1">
<xe:this.loaded><![CDATA[${javascript:if (sessionScope.databaseName == null) {
return false;
} else {
return true;
}}]]></xe:this.loaded>
</xe:calendarView>
If you need some more info, this example is included inside the DWA_iNotesRest.xsp.
I googled a long time and the only solution I`ve found is to build your own Rest service
have you managed to filter the Calendar without this?
Working on a REST API for work, and came across an issue where I want to pass a value that represents a relationship but also a URL of that relationship so that it could be compliant with HATEOAS.
I think I've come up with an appropriate solution, but would like some confirmation from those with more knowledge then me.
Would this RESTful JSON response still be compliant with HATEOAS principles?
{
"employee":{
"empId":12345,
"fName":"Bubba",
"lName":"Gump",
"title":"Shrimp",
"reportsTo":54321,
"hateoas":{
"self":"http://www.bubbagumpshrimp.com/rest/Employees/12345",
"reportsTo":"http://www.bubbagumpshrimp.com/rest/Employees/54321",
"directReports":"http://www.bubbagumpshrimp.com/rest/Employees/?reportsTo=12345"
}
}
}
So what do you all think? Will that format work?
Based on the suggestion from #fumanchu below, this is the format I'll try using for now...
{
"employee":{
"empId":12345,
"fName":"Bubba",
"lName":"Gump",
"title":"Shrimp",
"reportsTo":54321,
"hateoas":{
"collection":"http://www.bubbagumpshrimp.com/rest/Employees/",
"self":"12345",
"reportsTo":"54321",
"directReports":"12345/DirectReports"
}
}
}
Thanks for the guidance!
It "works" but it's redundant. Once you have the URI's why keep the bare id's that communicate nothing about their semantics or how they are to be used? I'd recommend you try this instead:
{
"employee":{
"self":"http://www.bubbagumpshrimp.com/rest/Employees/12345",
"fName":"Bubba",
"lName":"Gump",
"title":"Shrimp",
"reportsTo":"http://www.bubbagumpshrimp.com/rest/Employees/54321",
"directReports":"http://www.bubbagumpshrimp.com/rest/Employees/12345/directReports"
}
}
(There's no reason to expose the "directReports" resource as "?reportsTo=12345". It's always better to identify it by its meaning than by its implementation.)
If you are in control of your API and/or media type (and you must be in order to tell your clients where to expect URI's since JSON doesn't define any), you can even shorten that by declaring that the "reportsTo", and "directReports" values are URI's which are relative to "self":
{
"employee":{
"self":"http://www.bubbagumpshrimp.com/rest/Employees/12345",
"fName":"Bubba",
"lName":"Gump",
"title":"Shrimp",
"reportsTo":"54321",
"directReports":"12345/directReports"
}
}