I would like to get some advise on the best practices regarding implementing calculated fields in the schema.
Typical e.g.:
Class ABC contains fields: Field1...Field10
Field1...Field5 are 'static' fields.
Field6 = some operation(Field1,Field2)
Field7 = some operation(Field3,Field6)
Field8 = some operation(Field1,Field5,Field6,Field7)
Now, every time a create/update operation is done on any/all of Field1...Field5, fields Field6...Field10 need to be updated, in order.
What is the best (most efficient) practice to achieve this?
Also, is there some way (or on the Parse roadmap) to implement
Calculated fields in the Dashboard itself? And determine the formulas
there itself, while defining a field?
^ This has become sort of the prevalent way of defining Calculated fields in most modern database/database abstraction tools.
Hard coding every formula to detect a field/fields change, while maintaining the correct order of updates for the calculated fields seems to be too gargantuan a task for modern times.
Any advise on this is most appreciated!
Thanks.
Related
For a certain program I have some type-keywords values like this:
Program Type Keyword
PIM Kind Additional
PIM Period Education
PIM Phase Specialized
PIM Skills Professional
The type is a fixed value, but the keyword depends of the Program and type. I want to transpose this result in analytics by making 4 columns with the type. The result has to look like this:
Program Kind period phase skills
PIM Additional Education Specialized Professional
I have tried by editing the column formula and putting this formula:
CASE WHEN "Type"='Partial period' THEN "Keyword" END
and so on for each different type. But it doesn't give me the result I want. all the new columns are empty.
I also tried with a pivot table, but the keyword isn't a measure, so I don't think this will work.
can someone help?
This simply doesn't make sense in an analytical way. You have no fact, nothing you measure. So no chance of using FILTER...USING... for example.
Don't forget you're not in Excel or a drawing tool. You're in an analytics tool which tries to make sense out of data and not "show data in a weird way".
You have to model things nicely either in the data source itself or be clever in the construction of your RPD.
It's doable in the RPD but it will be quite static and if the list of values changes you will have to adapt it.
tl;dr - garbage data, garbage result
First time poster and a Freemarker novice. I'm hoping someone can assist on this. I am currently referencing data from a 1-to-many table using the <#data> directive. I want to sort the results in a particular field order, but I think that can only be done by the <#list> directive. Here's what I have so far:
There's a CART_ABANDONMENT table with the following fields:
CUSTOMER_ID_
PRODUCT_ID
PRODUCT_NAME
PRODUCT_PRICE
ABANDONED_DATE
<#data CART_ABANDONMENT as abandonment><br>
<#filter CUST_ID="${CONTACTS_LIST.CUSTOMER_ID_}"><br>
<#fields PRODUCT_ID PRODUCT_NAME PRODUCT_PRICE ABANDONED_DATE><br>
${abandonment.PRODUCT_NAME} ${abandonment.PRODUCT_PRICE}<br>
</#data>
What I want to do is to list all related results (by CUSTOMER_ID_) and sort them by PRODUCT_PRICE, descending.
It may be something simple, but I haven't been able to find the answer.
Any guidance would be appreciated.
Freemarker is powerful tool tool but it's just template engine.
It has the sort directive for list, but it can be applied only to built-in types: String, Number and Date.
You may convert list of you complex type to one or more lists of built-in types and use ?sort in template.
Another way is to pass already sorted(as you want) list to template before processing.
What you want sounds like something that should be solved on the database (SQL) level, especially where you say "list all related results (by CUSTOMER_ID_)". FreeMarker is only the V (for View) in MVC.
I've been doing a lot of reading lately on Cassandra, and specifically how to structure rows to take advantage of indexing/sorting, but there is one thing I am still unclear on; how many "index" items (or filters if you will) should you include in a column family (CF) row?
Specifically: I am building an app and will be using Cassandra to archive log data, which I will use for analytics.
Example types of analytic searches will include (by date range):
total visits to specific site section
total visits by Country
traffic source
I plan to store the whole log object in JSON format, but to avoid having to go through each item to get basic data, or to create multiple CF just to get basic data, I am curious to know if it's a good idea to include these above "filters" as columns (compound column segment)?
Example:
Row Key | timeUUID:data | timeUUID:country | timeUUID:source |
======================================================
timeUUID:section | JSON Object | USA | example.com |
So as you can see from the structure, the row key would be a compound key of timeUUID (say per day) plus the site section I want to get stats for. This lets me query a date range quite easily.
Next, my dilemma, the columns. Compound column name with timeUUID lets me sort & do a time based slice, but does the concept make sense?
Is this type of structure acceptable by the current "best practice", or would it be frowned upon? Would it be advisable to create a separate "index" CF for each metric I want to query on? (even when it's as simple as this?)
I would rather get this right the first time instead of having to restructure the data and refactor my application code later.
I think the idea behind this is OK. It's a pretty common way of doing timeslicing (assuming I've understood your schema anyway - a create table snippet would be great). Some minor tweaks ...
You don't need a timeUUID as your row key. Given that you suggest partitioning by individual days (which are inherently unique) you don't need a UUID aspect. A timestamp is probably fine, or even simpler a varchar in the format YYYYMMDD (or whatever arrangement you prefer).
You will probably also want to swap your row key composition around to section:time. The reason for this is that if you need to specify an IN clause (i.e. to grab multiple days) you can only do it on the last part of the key. This means you can do WHERE section = 'foo' and time IN (....). I imagine that's a more common use case - but the decision is obviously yours.
If your common case is querying the most recent data don't forget to cluster your timeUUID columns in descending order. This keeps the hot columns at the head.
Double storing content is fine (i.e. once for the JSON payload, and denormalised again for data you need to query). Storage is cheap.
I don't think you need indexes, but it depends on the queries you intend to run. If your queries are simple then you may want to store counters by (date:parameter) instead of values and just increment them as data comes in.
I'm fairly new to the more complex parts of Core Data.
My application has a core data store with 15K rows. There is a single entity.
I need to display a subset of those rows in a table view filtered on a calculated search criteria, and for each row displayed add a value that I calculate in real time but don't store in the entity.
The calculation needs to use a couple of values supplied by the user.
A hypothetical example:
Entity: contains fields "id", "first", and "second"
User inputs: 10 and 20
Search / Filter Criteria: only display records where the entity field "id" is a prime number between the two supplied numbers. (I need to build some sort of complex predicate method here I assume?)
Display: all fields of all records that meet the criteria, along with a derived field (not in the the core data entity) that is the sum of the "id" field and a random number, so each row in the tableview would contain 4 fields:
"id", "first", "second", -calculated value-
From my reading / Googling it seems that a transient property might be the way to go, but I can't work out how to do this given that the search criteria and the resultant property need to calculate based on user input.
Could anyone give me any pointers that will help me implement this code? I'm pretty lost right now, and the examples I can find in books etc. don't match my particular needs well enough for me to adapt them as far as I can tell.
Thanks
Darren.
The first thing you need to do is to stop thinking in terms of fields, rows and columns as none of those structures are actually part of Core Data. In this case, it is important because Core Data supports arbitrarily complex fetches but the sqlite store does not. So, if you use a sqlite store your fetches are restricted those supported by SQLite.
In this case, predicates aimed at SQLite can't perform complex operations such as calculating whether an attribute value is prime.
The best solution for your first case would be to add a boolean attribute of isPrime and then modify the setter for your id attribute to calculate whether the set id value is prime or not and then set the isPrime accordingly. That will be store in the SQLite store and can be fetched against e.g. isPrime==YES &&((first<=%#) && (second>=%#))
The second case would simply use a transient property for which you would supply a custom getter to calculate its value when the managed object was in memory.
One often overlooked option is to not use an sqlite store but to use an XML store instead. If the amount of data is relatively small e.g. a few thousand text attributes with a total memory footprint of a few dozen meg, then an XML store will be super fast and can handle more complex operations.
SQLite is sort of the stunted stepchild in Core Data. It's is useful for large data sets and low memory but with memory becoming ever more plentiful, its loosing its edge. I find myself using it less these days. You should consider whether you need sqlite in this particular case.
I'm trying to order search results using an equation that uses Products and User has inputs. In other words, I have an equation that uses data from both Products and current_user. I want to be able to order my search results by the number I get from the equation. I'm pretty lost on even were to begin with this. Has anyone done something similar or have any ideas of how to best handle the sort/order? From my understanding, "order" is usually used to sort actual columns in the SQL database and not a method.
I was originally thinking I would need to pass the current_user into the model. I know that's not best practice, but Sunspot allows you to create custom fields in the model and then sort on those fields. Unfortunately, this doesn't work since sunspot needs to index the fields it searches and sorts by.
I'm currently using Sunspot and would like to keep using it even if need to make modifications. I'm also using pagination.
You cannot calculate complex equations in SQL. You are restricted to simple calculations.
Possible Solutions:
Depending on how many results you get it might be possible to just
use the ruby sort method.
Calculate the result of your equation and store them in a new
column or table
Your problem could be associated with "matching".