Is it possible to create a RescorerProvider to filter out elements which are associated with a specific tag? Or should I implement an own model with relevant data as in the book "mahout in action" on page 79?
Route: /recommend/?rescorerParams=sports
Push score of elements which are associated with tag sports
For this you would have to separately track which items are associated to which tags. This information is not queryable within the server itself. But you can periodically cache this info from an external source and then apply whatever logic you like based on tags. Yes, it is kind of like what's in Mahout in Action.
Related
I am creating a Query using the Rally/Excel plug-in. I am creating the report with a base type of Task but want to include User Story information in the Query.
I have been able to do this before by adding "WorkProduct.Release" into the columns listing. That works no problem. When I attempt this with a custom field named "CR#" I get no contents being returned.
I am able to pull custom fields from the Task itself without issue it just appears to be an issue when pulling from the parent object.
I have verified the field name and that the content is actually populated. Does anyone know a way to pull this data via the excel plug-in or if there is a limitation with pulling custom field information from a parent?
In Web Serivces API Workproduct attribute is Artifact. Artifact is a parent of Task, HierarchicalRequirement (user story) and Defects, and other work item types. Those types can have custom fields created on them, but the parent Artifact is not aware of them. It is not possible to traverse from Artifact to a custom field, and it should also not be possible to traverse to Iteration or Release from Artifact. Those fields do not exist on Artifact object in the API. It is possible to traverse Workproduct.FormattedID because FormattedID attribute exists on Artifact. That's where work item types inherit the FormattedID from. If I use Workproduct.Release or Workproduct.Iteration in Excel plugin in a query on a Task object following this syntax:
(Workproduct.Iteration = /iteration/12352898163)
I get this error:
(Workproduct.Iteration.Name = it123)
will produce a similar error.
I put this to the Rally Support folks and got the following answer, so the short answer is no...can't be done:
When you query using WorkProduct.FormattedID on a task, the data can
be returned because that field is part of "Artifact". You can see
this by looking at the Web Services API information, which I have
included some screenshots to illustrate this. The custom field you
are trying to query doesn't reside on Artifact, so is not found by the
query.
The actual work product that has your custom field would be either a
defect or a story, but the Task object does not reference back to that
to allow you to query.
You could do another query for the different work products and include
the custom field, then combine the two worksheets.
I have defined my own projection by a query which returns a set of content items of known content type. I would like to take pick up certain content parts of these content items and display them in the list. Using shape tracing tool I have found the view template where to write my custom layout:
/Views/Parts.ProjectionPart.cshtml
but from the Model variable in the template I can not get the data I want because it is way too high above from the content parts data.
a good example of what I want: let's say I want to render product catalog as defined in this tutorial:
http://skywalkersoftwaredevelopment.net/blog/writing-an-orchard-webshop-module-from-scratch-part-5
but I want only to render a list which consists from items:
name of the owner who created the product
name of the product.
publish date of the product
and I need to render it at one place, i.e., not separately in their own part views.
Have you tried adding a layout in the projector module? There is a properties mode option that lets you select which fields/data to show. If the data you want is not there, you should be able to implement an IPropertyProvider. There are examples of this in the Projections module code.
I have an odd issue.
I have client that wants a sharepoint list what is populated from a WCFService. That part is working quite well.
I have a bdcmodel that is mapping the WCF data and I can create an external list from the bdcmodel as well so that is working fine.
The issue I have is that one of the properties in the model is actually a collection of entities called Attributes. The objects in this collection simply have 2 properties Name and Value so really they are just a key value pair.
The client wants to see the list of attributes of the parent entity in the external list. So there would be an Attributes column and within that column would be the list of attributes for each parent object.
Is there even a way to do this? I am looking into Custom Field Types, but it seems like these are really intended to be singular values.
How would I create a list within and external list?
Any help anyone can give would be great even if its just to tell me that there really isn't a stable way to do this so I can go back to the client and tell them we will need to build a custom list to support this because the OOB external list and custom fields and custom field types won't support this kind of nested listing.
I decided to set up the custom field as a string and when I get my collection in from the BdcModel I am serializing it to JSON and then passing it to the field. When the field is viewed in display, edit or new I have overridden the FieldRenderingControl and I am tiling the collection out that way.
I am designing an application that will display dynamically-generated forms to the user who will then enter values into the form fields and submit those values for persistence. The form represents an employee evaluation.
One use case allows an administrator (from HR) to define the form fields. They should be able to create a new form, add/remove fields from a form and mark a form as 'deleted'.
The second use case is when a manager views the form and enters values into the form fields for a specific employee. They should be able to save the values at any time and recall the saved values when viewing the form again for the same employee.
Finally, when the manager is satisfied with the values they've entered for that employee, they can 'submit' the form data which persists the flattened data into the data warehouse for reporting purposes. When this is done, the 'working' copy of the data is removed so the form will display empty the next time they view it for that employee.
I am not concerned with the front-end at this point and working on the back-end service application that sits between the client and the data store. The application must provide a course-grained interface for all of the behavior required.
My question is how many aggregate roots do I actually have (and from that, how many repositories, etc)? Do I separate the form definition from the form data even though I need both when displaying the form to the user?
I see two main entities, 'EmployeeEvaluationSchema' and 'EmployeeEvaluation'. The 'EmployeeEvaluationSchema' entity would have a collection of 'FieldDefinition' value objects which would contain the properties that define a field, the most basic being the name of the field. The 'EmployeeEvaluation' entity would have a collection of 'FieldValue' value objects which contain the values for each field from the definition. In the simplest case, it would have a field name and value property. Next, the 'EmployeeEvaluation' could have a reference to 'EmployeeEvaluationSchema' to specify which definition the particular evaluation is based on. This can also be used to enforce the form definition in each evaluation. You would have two repositories - one for each entity. If you were to use an ORM such as NHibernate, then when you retrieve a 'EmployeeEvaluation' entity, the associated 'EmployeeEvaluationSchema' would also be retrieved even though there is a dedicated repository for it.
From your description it sounds like your objects don't have any behavior and are simple DTOs. If that is the case maybe you should not bother doing DDD. Can you imagine your entities without having getters? There are better ways to do CRUDish application than DDD. Again this is only valid if your "domain" does not have relevant behavior.
I am wondering if the following scenario would be amenable to CouchDB? I am building a web-based flashcard application. Users can create flashcards (question on one side, answer on the other). Flashcard authors and other users can tag flashcards with keywords/phrases. Users can retrieve/generate virtual stacks of cards based on tags including support for boolean search (tagA AND tagB NOT tagC OR tagD). The DB will store cards (obviously) but also “documents” for users, tags and potentially virtual stacks of cards. I have read other SO questions concerning tagging within CouchDB but am wondering if the following would work or be to write intensive … (1) Card documents contain JSON array of tag strings assigned to that card, (2) Tag documents contain JSON array of cards using the tag, (3) tag documents also have element to store count of cards using that tag, (4) whenever a new card is created or tag is added to a card, the associated card identifier is also added to the tag document and the tag document's CardCount element is incremented. (5) Permanent views of cards indexed by card ID and of tags indexed by tag string are generated. If I know the card ID I can find the document quickly and can quickly get a list of associated tags. If I am given a tag string I can quickly find the tag document and then get a list of card IDs using the tag. For more elaborate boolean search I can retrieve a list of card IDs for each tag in the boolean search and then figure out the union/intersection/etc of these sets on the client. Does this seem reasonable? I am aware of the fulltext indexing option using Lucene but would like to avoid this if possible. Thanks.
I don't see a good reason to make things that complicated - just create a document per card and add tags to these documents as you go along. Create a few stored views to count/show tags and their usage number when you need it.
this way you'll only need:
card document:
question
answer
tags[]
views:
show card info
show (perhaps most popular) tags
show cards per tag
As long as your documents are properly structured, you won't need full text search to handle everything.