I have a content type that stores two numerical values, effectively the minimum and maximum of a range.
I would like to configure the views module filter so that it will display nodes where the node range is contained within or overlaps a range specified in the view.
Views does not allow mixed OR and AND filters. You can configure an existing filter to show all nodes where N > 30 AND N < 50 (between, excluding, 30 and 50).
If you want more complex filters, e.g. filters that have business logic, or filters that create either/or conditions, you can define them yourself, trough hook_views. This is badly documented and requires a lot of googling and reading existing filter code.
Related
I will be creating a MS Access form based on a hard copy. The hard copy has a column of labels and then 3 columns of fill-in-the-blank.
The problem is that there are 30 categories which means 90 fields if it were to be a continuous form. If it is not a continuous form then the categories must be selected one by one from the drop down.
Is there a way to set the categories static - possibly give each a different code - but have just the 3 fields in the table rather than having 90 fields?
Or perhaps, can the drop down be a permanent list?
The data model I am planning would have a few property "fields" in place, including a "category/tags" property, which would be a list/array of a lot of tags.
I'm planning on querying on one category at a time. I am not interested in indexing which entities have combinations of categories, just individual categories.
I am NOT referencing simply not indexing a particular property.
Bonus Question:
It seems Google datastore doesn't like "monotonically increasing" property values (ie timestamps) because presumably they make hotspots on the machines while forming indexes. So would just storing the current calendar date help? I could see that making even more of a "hotspot" since every entity for 24 hours would have the same index value for that property, is there some way of storing some data about when each entity was recorded?
Indeed, one should encounter no issues creating a builtin index, as mentioned in the above reply. Still, properties with array values can behave in surprising ways. For more than one filter, all conditions defined by the filters must be satisfied by at least one of the array’s individual values, for it to match the query. This does not apply in case of the equality filters.
Sort order is also unusual: the first value seen in the index determines an entity's sort order.
I don't think a property index (aka Built-in Index) on an Array property creates the index with various value combinations. I believe each value in the Array is indexed. For example, if you have a Book with two tags, the index will have two entries for each tag. Adding another book with three tags would add 3 more entries to the Tags index. This index allows you to query for books based on a single tag as well as multiple tags.
The "combination of values" that you mentioned happens if you create a composite index containing more than one Array type (e.g. Authors and Tags of a Book), and all/most books have multiple authors and multiple tags.
You should not have any issues creating a builtin index on your Category/Tag.
On your other question on indexing entity created/modified timestamp, I do see that the Best Practices says to avoid indexing such a property.
Do not index properties with monotonically increasing values (such as
a NOW() timestamp). Maintaining such an index could lead to hotspots
that impact Cloud Datastore latency for applications with high read
and write rates
Not sure what the alternative would be. If you don't have to query on the timestamp/sort on the timestamp, you are fine storing the timestamp by excluding the property from indexing.
I created a cube that contain five attributes and a metric and I want to create a document from this cube with different visualisations for each attribute. the problem is that data in the cube are aggregated based on all attributes in the cube, so when you add a grid with one attribute and the metric the numbers will not be correct.
Is there any way to make the metric dynamically aggragate depending on the attribute in use?
This depends what kind of metric you have in the cube. The best way to achieve aggregation across all attributes is obviously to have the most granular, least aggregated data in the cube, but understandably this is not always possible.
If your metric is a simple SUM metric then you can set your dynamic aggregation settings on the metric to just do SUM and it should perform SUM's appropriately regardless of the attributes you are placing on your document/report? Unless your attribute relationships are not set up correctly or there are some many-to-many relationships taking place between some of those attributes.
If you metric is a distinct count metric, then the approach is slightly different and has been covered previously in a few places. Here is one, on an older version of Microstrategy but the logic can still be applied to newer versions.:
http://community.microstrategy.com/t5/tkb/articleprintpage/tkb-id/architect/article-id/1695
In the Crossfilter documentation, it states the following.
a grouping intersects the crossfilter's current filters, except for the associated dimension's filter. Thus, group methods consider only records that satisfy every filter except this dimension's filter. So, if the crossfilter of payments is filtered by type and total, then group by total only observes the filter by type.
What is the reasoning behind that and what is the way around it?
The reason is that Crossfilter is designed for filtering on coordinated views. In this scenario, you are usually filtering on a dimension that is visualized and you want to see other dimensions change based on your filter. But the dimension where the filter is defined should stay constant, partially because it would be redundant (the filter mechanism is usually displayed visually already) and partly because you don't want your dimension values to jump around while you are trying to filter on them.
In any case, to get around it you can define two identical dimensions on the same attribute. Use one dimension for filtering and the other for grouping. This way, as far as Crossfilter is concerned, your filtering dimension and grouping dimensions are separate.
I have a CCK field price which the user can fill in. I would like to create a search form with dropdown price field with different ranges (such as below 100$, 100$-1000$, more than 1000$). The problem is that the user input is an integer so I cannot achieve range search using filter exposure. The user would have to specify the exact value to perform searching, but this is rather useless. Is there a way ( amodule, etc) to create ranges out of integer values so that the user is able to perform range based search?
Obviously people grab views and CCK for most solutions. But often a small module sith just a hook_menu(), a calback and a theme function will suffice.
In that callback you can perform whatever complex query you want.
Such modules, most of the time, contain less then 100 lines of PHP.
If you know PHP such a functionality might take you less then an hour to build. Whereas writing addons and behaviours for CCK and Views often costs much more.
The advantage of building views and CCK addons, is that your code is better re-usable.
The way I did it in the past was to use hook_form_alter to change that field to a select drop down range (a min and max drop down), then alter the views query if a value was provided.
The other way to do ranged facets would be to explore Apache Solr integration or Search Lucene facets. Keep in mind that its not exactly plug n play tech, though.
To sort out out your price into various categories you need to create a CCK Select list and then populate the list automatically using the Rules module. You need to also hide this select list using content permissions.
I've created a mini-case study on graphing using Rules & Views. As part of the mini case study, it shows you how to categorize the cost field using Rules -- which is precisely what you want. It also shows you how to hide the field using content permissions. Please check the below link for a video:
http://www.noparrots.com/content/mini-case-study-creating-a-bar-chart-in-drupal