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.
Related
I am wanting to show a list of all users for a particular app in holochain to enable an active user to make an agreement with someone. What is a best practice for getting a list of all users given the linking nature of the data flow?
Would it make sense to create a central agent that links to all the users to get access to the full user list? Is there a way that seems better?
Link from the DNA Hash (not recommended; read about anchors below)
Each user could link from the DNA hash to themselves in the genesis() function -- the DNA hash is the one hash on the DHT that everyone knows. Then all you need to do is getLinks(App.DNA.Hash, "user") to get them all. (watch out, it could get to be a huge list. I also feel bad for the poor nodes who are in the neighborhood of the DNA hash... that's a lot of metadata to store.
Doing this in Genesis
This can be done in the genesis function. I'll do it in old holochain-proto language, if you don't mind:
function genesis() {
commit({ Links: [ { Base: App.DNA.Hash, Link: App.Key.Hash, Tag: "registered_user" } ] };
}
That will create a sort of 'registered agent' thing for each new person who joins.
The problem with this approach
it's a bit of an antipattern, because a redundant copy of the DNA lives in the DHT as well, and the poor souls whose nodes are in the DHT hash neighbourhood of the DNA will have a higher load than others. Right now I'd recommend anchors instead. Anchors are nothing but a pattern that consists of a string entry + a link. So you would create an anchor whose content is "registered_users", and link from that anchor to any agent who comes on board. Still creates a hotspot for those who hold the anchor entry, but it's expected that your app will have a few anchors like this, and at least they don't have to all hang off the one DNA hash.
Linking with Anchors
The anchors mixin (currently compatible with hc-proto only) features an idempotent function to create the anchor, so each user could safely call anchor() without re-creating an existing anchor.
I am putting my collection of some 13000 books in a mySQL database. Most of the copies I possess
can be identified uniquely by ISBN. I need to use this distinguishing code as a foreign key into
another database table.
However, quite a few of my books date from pre-ISBN ages. So for these, I am trying to devise a
scheme to uniquely assign a code, sort of like an SKU.
The code would be strictly for private use. It should have the important property that, when I
obtain a pre-ISBN publication, I could build the code from inspecting the work, and based on the
result search the database to see if I already have other copies in my possession.
Many years ago I think I saw a search scheme for some university(?) catalogue, where you could
perform a search of a title based on a concatenated string' (or code) that was made up of let's
say 8 letters from the title, and 4 from the author, and maybe some other data. For example,
to search 'The Nature of Space and Time' by Stephen Hawking and Roger Penrose you might perform
a search on the string 'Nature SHawk', being comprised of 8 characters from the title (omitting
non-filing words and stopwords) and 4 from the author(s).
I haven't been able to find any information on such scheme's, or whether or not such an approach
was standardized in any way.
Something along these lines could be made up of course, but I was wondering if people here have
heard of such schemes, of have ideas on how to come to a solution to this.
So keep in mind the important property of 'replicability': using the scheme, inspection of a pre-
ISBN dated work should --omitting very special or exclusive cases-- in general lead to a code
that can singly be used to subsequently determine if such a copy is already in the database.
Thank you for your time.
Just use the Title (add Author and Publisher as options) and a series id to produce a fake isbn. Take a look at fake_isbn.
NOTE: use the first digit as a series id but don't use 9!
Default a submitter (uploader) of a document can add self chosen keywords to that document.
It is also possible to configure DSpace in a way that the submitter has to choose from one or more predefined keywords (controlled vocabulary).
The DSpace manual seems to suggest that you - when configuring - have to choose between free and predefined keywords.
I would like to give the submitter the possibility to choose between one or more predefined keywords. But also that he or she can add one or more self chosen keywords.
Is that possible?
The hierarchical taxonomy feature gives you exactly this:
https://wiki.duraspace.org/display/DSDOC5x/Authority+Control+of+Metadata+Values#AuthorityControlofMetadataValues-HierarchicalTaxonomiesandControlledVocabularies
You can see it in the demo installation on the "subject" field: you have a lookup feature that allows lookup in a tree of subjects, but manually entered values are possible as well.
screencast:
http://screencast.com/t/0Cth3mORwxd
I personally would set this up to use two different metadata fields.
Something like dc.subject.whateverdescribesyourlistoffixedterms -- or even localschema.subject.whateverdescribesyourlistoffixedterms -- for the list of terms the user should select from. Note, for "whateverdescribesyourlistoffixedterms" I would choose something related to the name of the list of terms if at all possible (see example below).
dc.subject for "standard" user-supplied keywords
Then just add both to your input forms, perhaps going with Bram's suggestion of a hierarchical taxonomy for the first.
To give you better advice on what's most appropriate, it would be great if you could give some more details about what you're trying to achieve. For example
Is your list of fixed keywords something that's used beyond your own organisation? If yes, this strongly points to having its own metadata field to me, with the qualifier something that's related to the name of the classification system -- eg, dc.subject.anzsrc for the Australia/New Zealand fields of research codes.
Do you want to mix the two types of keywords in browse/facet options? You can do this even when they're in two separate fields. Have a look at the Discovery search filters & sidebar facets documentation and see how that puts dc.contributor.author and dc.creator into the author facet. The documentation for browse indexes has a similar example in the author browse.
Are both types of subject keywords required for submission? Both optional? One type required, the other type optional? You say in a comment (if I read you correctly) that you want the fixed keywords to be mandatory during submission, while the free-text keywords should be optional. That means they must be in separate metadata fields because otherwise you wouldn't know, if the submitter gives keywords, whether they are from the fixed list of terms or not. If you use separate fields, you can make eg dc.subject.anzsrc a required field in the submission form and dc.subject an optional one.
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.
I am working with the VSO REST API and have a question on how Iteration and Area ID's are assigned. Specifically, why is it when I assign a work item to the root Iteration or Area the ID that is returned for the WIT is not returned when I query the classification nodes?
For example, imagine I have this hierarchy when I query /DefaultCollection/my project/_apis/wit/classificationnodes?$depth=2
My Project: id=1234
Area 1: id=5678
Area 2: id= 9012
And I then query for a work item using /DefaultCollection/_apis/wit/workItems/1?$expand=all
If the work item is in Area 1 or Area 2, the System.AreaId field is as expected (5678 and 9012, respectively). However, if I assign the work item to My Project, the System.AreaID is some value that is not included when I query for all classification nodes. There appears to be some kind of relationship between the ID's as they are serial (e.g. the ID returned by the classification node query is 1232 for the area and 1233 for the iteration), but I can't seem to find a way to query to get the actual ID returned by the work item query.
In fact, not only is the ID returned for a work item not present when I query for all classification nodes, if I assign the work item to both the root iteration and area, the ID returned for both fields is the same value that is not included in the classification node query.
What I need is a way to look at a work item and figure out the area and iteration it belongs to. I could probably do something with the path field strings that are returned, but that seems error prone since users can change them.
****Edit****
The above appears to be a bug in the REST API, but for anyone who comes across this post there is a way to get a usable iteration ID by the path string. Structure your REST call like so:
/DefaultCollection/[Project Name]/_apis/wit/classificationnodes/iterations/Release 1/Sprint 1 (etc.)
I have never done this with ID. I only use the path. In the classification service you can get the node by path easily enough.
For example, using the REST API - you can access this url to get the data about a specific iteration:
/DefaultCollection/[Project Name]/_apis/wit/classificationnodes/iterations/[Release X]/[Sprint Y]
Note that trying to access the default iteration path (the project name instead of a specific iteration) will return an error:
/DefaultCollection/[Project Name]/_apis/wit/classificationnodes/iterations/[Project Name]
will give :
{"$id":"1","innerException":null,"message":"VS402485: The node name is not recognized: [Project Name]","typeName":"Microsoft.TeamFoundation.WorkItemTracking.Server.Metadata.WorkItemTrackingTreeNodeNotFoundException, Microsoft.TeamFoundation.WorkItemTracking.Server","typeKey":"WorkItemTrackingTreeNodeNotFoundException","errorCode":0,"eventId":3200}
So if you do batch work, you have to filter those before querying the api.
There are three ways of identifying an Area (everything I post equally applies to Iterations also). The Path (string), the ID (int) and a Guid. each of them are used in different ways, and have different ramifications.
For example renaming an Area, does NOT change it's identity, therefore does not update a work item (the path returned for in a workitem is dynamic).
It is also possible to delete and recreate and identical path, but it will have a different ID.
The GUID is used primarily for the Excel Reports (such as are parent of the SharePoint portal)
Depending on how you want things to react determines the appropriate element to use.
I have not seen any issues with the ID that you mention, and if you could create a simple repro, I would be glad to look at it.
david(dot)corbin(at)dynconcepts(dot)com