Does Couchbase document expiration affect documents which reference the expired document ? E.g. in the "Modelling documents for retrieval" section of the documentation, there are crater documents which reference asteroid documents as follows:
"crater_id" : "crater1",
"on_asteroid" : "asteroidA"
Now, if the document with ID "asteroidA" were to expire, would that affect this record for this crater crater1?
No. A document's TTL (expiry) affects just that document.
Related
I am trying to find only the current period concepts and facts for the three main financial statements. The goal is to be able to iterate through filings of different companies in different periods.
Using Ebay 2017 10-k as an example.
For concepts that capture YoY change, like those in income statement and statement of cash flows, I can use context found in any of the dei tags, for example:
<dei:DocumentFiscalYearFocus contextRef="FD2017Q4YTD" id="Fact-2E3E1FD4D81352F693510AE035FDC862-wk-Fact-2E3E1FD4D81352F693510AE035FDC862">2017</dei:DocumentFiscalYearFocus>
dei:DocumentFiscalYearFocus tag is required, and its context "FD2017Q4YTD" is also found in all IS and SCF period end concepts, so that's easy.
However, balance sheet concepts use a different context:
<us-gaap:CashAndCashEquivalentsAtCarryingValue contextRef="FI2017Q4" decimals="-6" id="d15135667e874-wk-Fact-3E4A0A2B272B59DE9DAF004097ECF968" unitRef="usd">2120000000</us-gaap:CashAndCashEquivalentsAtCarryingValue>
Any idea how to identify the "FI2017Q4" context (or otherwise find current period balance sheet concepts)?
The XBRL document instance you are viewing contains one or more schemaRef elements, each of which loads an XBRL taxonomy, or data dictionary, for the XBRL instance. Somewhere, within that reference graph of files (and there could be several files), is the definition of each context. The definition will look something like this:
<context id="CONTEXT_ID_NAME">
<!-- ... child elements appear here ... -->
</context>
If you can find the <context> element with an attribute of id that matches the contextRef you're interested in, then you've found what you're looking for. In your case, you're looking in the related XBRL taxonomy files for something that says <context ID="FD2017Q4YTD"> and <context ID="FI2017Q4">.
The child elements of the <context> element describes the dates for the context. There are two types of XBRL contexts:
instant, which specifies a context with a single date
period, which specifies a context with a start date and an end date
The child elements of the <context> element will describe which type of context being described.
This work is all manually doable, but it might be best to use XBRL processing software, which will perform all of this work for you.
The value of the contextRef attribute is purely an identifier that references a context definition elsewhere in the document. Using the eBay example, you'll find this context definition:
<context id="FI2017Q4">
<entity>
<identifier scheme="http://www.sec.gov/CIK">0001065088</identifier>
</entity>
<period>
<instant>2017-12-31</instant>
</period>
</context>
The value in the "instant" element is what tells you what date facts associated with this context relate to.
In order to properly understand the XBRL facts, you need to fully understand the associated contexts. There may be other information, such as additional dimensions, defined here.
I'd strongly recommend working with an existing XBRL processor that will resolve the contextual information for you, such as the open source Arelle processor, or the API provided by XBRL US.
One possible approach to working with XBRL data is to use a processor that converts data to the newer xBRL-JSON format, which provides fact objects with all contextual information fully resolved.
I have found a reference cycle in the DAG defined by "categorylinks" and "page" tables inside the japanese Wikipedia database.
Is this a bug in the data?
Page ids reference cycle:
2904319 -> 133683 -> 988775 -> 424676 -> 2904319
(行動 -> 生活 -> 人間関係 -> コミュニケーション -> 行動)
I am considering only sub-categories (page_namespace = 14).
In the Wiki Category documentation it explicitly states that:
All categories (except root category 1) should be contained in at least one other category, and there should be no cycles (i.e. a category should not contain itself, directly or indirectly).
Could the data be broken?
Am I misunderstanding anything?
The data is probably not broken. There is nothing in MediaWiki that prevents category loops, or cycles. Category structures like A < B < C < A are valid, and not uncommon in MediaWiki installations. Categories can also be orphaned, not belonging to any category.
The text you are quoting is not from the MediaWiki documentation, but from a Wikimedia help page. It refers to a recommendation by Wikimedia to try and keep categories hierarchical on Wikimedia wikis (e.g. Wikipedia). However, as this depends on the editors, you will find plenty of exceptions in any major Wikimedia wiki. Sometimes they are unintentional, and sometimes they are considered acceptable by the community for one reason or another.
A more relevant place to look in your case, is the corresponding help page, and the policy page for categories on Japanese Wikipedia. You'll find them here:
Help:カテゴリ
Wikipedia:カテゴリの方針
While going through the definition link base of a taxonomy, i found that a few domain members were present in two separate dimensions. Eg. Dim A contains domain Dom1 with members m1, m2,m3,m4. And Dim B contains domain dom2 with members m2,m3,m4. The issue is that it may lead to conflicting context names (even though the segment part of the contexts will be different).
The format of the context name is 'periodInformation_domainMember'. I need to use different dimensions for different sections of my report. So my basic question is how do i form context names?
I hope i have conveyed myself properly.
Appreciate any help... :)
use "Period Information + Dimension + member name" for making context names unique.....
You have to check the uniqueness based on the child nodes of <period> tag and child nodes of the <segment> tag... here in segment; if segment is present then each xbrldi:explicitMember has dimension in its attribute and member in its value...
...more: http://www.xbrl.org/Specification/XBRL-RECOMMENDATION-2003-12-31+Corrected-Errata-2005-04-25.htm#_4.7
What if there were multiple dimensions? Playing devil's advocate, what if you have dimensions with the same local name but in different namespaces? The only way to guarantee a unique name is to use the whole content of the context - which is ridiculous.
I've seen recommendations by regulators requiring filings in XBRL that 'Semantics SHOULD NOT be expressed...' in a context id and it is '..recommended to keep it as short as possible...'
The simplest solution is to pick unique names that that have nothing to do with the contents - for example c-1, c-2 etc.
The syntax of the XBRL is unimportant, it's just an implementation detail.
I have been digging through IBM knowledge center and have returned frustrated at the lack of definition to some of their scripting interfaces.
IBM keeps talking about a containment path used in their id definitions and I am only assuming that it corresponds to an xml element within file in the websphere config folder hierachy, but that's only from observation. I haven't found this declared in any documentation as yet.
Also, to find an ID, there is a syntax that needs to be used that will retrieve it, yet I cannot find a reference to the possible values of 'types' used in the AdminConfig.getid(...) function call.
So to summarize I have a couple questions:
What is the correct definition of the id "heirachy" both for fetching an id and for the id itself?
e.g. to get an Id of the server I would say something like: AdminConfig.getid('/Cell:MYCOMPUTERNode01Cell/Node:MYCOMPUTERNode01/Server:server1'), which would give me an id something like: server1(cells/MYCOMPUTERNode01Cell/nodes/MYCOMPUTERNode01/servers/server1|server.xml#server_1873491723429)
What are the possible /type values in retrieving the id from the websphere server?
e.g. in the above example, /Cell, /Node and /Server are examples of type values used in queries.
UPDATE: I have discovered this document that outlines the locations of various configuration files in the configuration directory.
UPDATE: I am starting to think that the configuration files represent complex objects with attributes and nested attributes. not every object with an 'id' is query-able through the AdminConfig.getid(<containment_path>). Object attributes (and this is not attributes in the strict xml sense as 'attributes' could be nested nodes with a simple structure within the parent node) may be queried using AdminConfig.showAttribute(<element_id>, <attribute_name>). This function will either return the string value of the inline attribute of the element itself or a string list representation of the ids of the nested attribute node(s).
UPDATE: I have discovered the AdminConfig.types() function that will display a list of all manipulatible object types in the configuration files and the AdminConfig.parent() function that displays what nodes are considered parents of the specified node.
Note: The AdminConfig.parent() function does not reveal the parents in order of their hierachy, rather it seems to just present a list of parents. e.g. AdminConfig.parent('JDBCProvider') gives us this exact list: 'Cell\nDeployment\nNode\nServer\nServerCluster' and even though Server comes before ServerCluster , running AdminConfig.parent('Server') reveals it's parents as: 'Node\nServerCluster'. Although some elements can have no parents - e.g. Cell - Some elements produce an error when running the parent function - e.g. Deployment.
Due to the apparent lack of a reciprocal AdminConfig.children() function, It appears as though obtaining a full hierachical tree of parents/children lies in calling this function on each of the elements returned from the AdminConfig.parent(<>) call and combining the results. That being said, a trial and error approach is mostly fruitful due to the sometimes obvious ordering.
I'm designing my back-end. I have a json array/queue/something which I only need any data that is at most 2 weeks old, that is continuously appended to. I only want to delete from this "queue", but not the container document. Can I use TTL for this, or does TTL only work for whole documents?
Is there a better way to do this? Should I store them in per-day or per-hour arrays as separate documents instead?
Running couchbase 2.2.
TTL in Couchbase only applies to whole documents, it's not possible to expire subsets of a document. Like you said you can always have separate documents with different expiry times in which you have a type,date and then the array of data as an element.
Then using a view like so:
function (doc, meta) {
if(meta.type == "json") {
if(doc.type == "ordered_data") {
if(doc.date) {
emit(dateToArray(doc.date));
}
}
}
}
You could emit all the related data ordered by date (flag descending set to true), it'd also allow your app to select specific dates by passing in one or more keys. I.e. selecting a date range of 2days,1week etc. When the document expires it'd be removed from the view when it updates (varies based upon your stale parameters plus ops a second/time).
Then you can do whatever joining or extra processing you need at the application layer. There are other options available but for me this would be the most sensible way to approach the problem, any problems just comment and we'll try again.
P.s. How big are you arrays going to become? If they are going to be very large then perhaps you'd need to look at a different tech or way to solve the problem.