Ray Light's dashboard

Hi Ben,

Thanks for sharing this one with us. We have heard this before, and we are definitely exploring the options available. I'll keep you posted as I learn more.

Thanks!
Ray

The situation has been resolved and the platform is back up and running. Apologies again for the inconvenience. The issue was related to network connections to internal servers and I am told the problem is fixed and should be back to normal.

We are monitoring the situation, and will take steps to make sure this doesn't happen again in the future.

Thank you for understanding!

Hi David,

Thanks for your interest in Good Data! Your idea is a great one, and we currently don't have anything in place to do this at the moment. However, we agree this is a great feature and plan to implement something like this.

In the meantime, I would like to bring to your attention a tool we have to make automatic uploading easier. There is an automated upload script you can use to append new data to your data sets (or overwrite them completely). You can download the script and learn more about it here:
http://support.gooddata.com/forums/46...

I hope this helps!

Ray

Hi Brent,

Thanks for sending the detailed information. I think I know why you are experiencing your problem, but I tried to create the report myself to make sure.

To create your report, I first added all the metrics (WHAT's) to the report and viewed the table. Then I added the State attribute (HOW). This created a report with 50 rows, one for each state as expected.

Then I went back and I added the City attribute. This took a little while, but the report finally displayed. At this point, the report contained over 50,000 rows of data x 8 columns of calculations. The delay comes from computing these 400,000 values, but at this point, everything seems well.

Finally, I added the zip code data to the report. Bear in mind that the application contains over 35,000 zip codes. At this point the application needs to compute the metric values for 8 metrics for every State/City/Zip combo. This is several million calculations and took several minutes.

In the end, I was able to produce the report you specified, but it was quite large and took over 5 minutes to compute. With a report this large, there may also possibly be problems passing this information and opening it within your browser. If you waited around 5-8 minutes for the report to compute and didn't see anything, then I am guessing the problem is coming from your browser not being able to display such a large table.

As a workaround, I would recommend breaking this report down into several smaller reports. For example, you could choose City and ZIP for one state. This would greatly limit the amount of rows that need to be passed to the browser, and should compute and display in a reasonable amount of time, not to mention be easier to digest :-)

Hope this helps, and please let us know if you have any other questions or concerns.

Ray

Hi Tom,

Thanks for suggesting this. I will forward this suggestion around the office, where I'm sure it will spark some healthy debate. :-)

Ray

Hi Brent,

Thanks for reporting this problem. I will try to diagnose the problem by replicating your report here. Can you please tell the choices you selected (7 What's and 3 How's)? I will create the exact the same report, and see if I can determine why this is hanging for you.

Thanks,
Ray

Hi Manuel,

Currently, our date attribute doesn't accept time stamps. If you split your column and have the date listed as dd/mm/yyyy, the application will recognize it as Date (US format).

One note, in addition to format, the application will recognize dates during upload only if there are a sufficient number of rows in the data set. If there are not enough rows to trigger the recognition mechanism, you can still map your attribute to Date after upload using the data management tools (Data > Data Sets > Join With Other Data Set > Time (Date)

Hope this helps!
Ray

Hi Tom,

The mechanism that matches the column data to date needs requires a minimum number of values to match before asking during the upload. My best guess at the moment is that the data set your are trying to load is to small to trigger the recognition mechanism. Even with this limitation, you should be able to map the date after the upload.

I know I am making some assumptions here, so please let me know if I am incorrect about the number of rows being uploaded.

Thanks,
Ray

Hi Tom,

Unfortunately, at this time, there is no easy way to update an existing data set with additional columns of data. This is a known shortcoming on our end, and we are working on allowing a more fluid data model that would allows exactly this. At this point, I'm not sure where this falls on the product roadmap, but I will let you know once this is upcoming.

Thanks,
Ray

Great... Glad this is working! :-)

Hi Tom,

Thanks for reporting this issue! I am currently unable to reproduce this, but I will continue trying different things to try to isolate the problem, and hopefully we can fix this quickly. If you have any additional insight into this, please let me know!

Thanks,
Ray

oh, and look for some additional improvements in the next couple weeks :-)

Glad you like it! I'll be sure to send your feedback to the guys :-)

I was just writing a response when I saw that you were able to get it working. I'm glad it worked for you!

Your question can be broken into two parts:

1) If you upload an incremental upload, then you don't have to do the mapping again. The application knows that some attributes are mapped and will automatically perform the mapping to the new data (provided that the data CAN be mapped--ie, that there is a corresponding value in the lookup table).

2) Unfortunately, the present state of the application doesn't let you easily "add columns" to a previous data set. In this case, the data would need to be loaded as a new data set and the mapping would have to be re-done.

This is a limitation we are aware of, and are working towards a more fluid data model that allows adding more columns as needed. At this point, I am not sure where this feature falls on our roadmap.

I'm glad you were able to get something working, and feel free to contact us with any other questions.

Hello Arjen,

Thank you for your suggestion! This is something we definitely have on our roadmap.

In the short term, I am happy to inform you that we do have something planned that addresses this situation. Admins will be able to define specific attribute value filters to individual users.

Then, reports can be created that look to the user profile for the specific attribute values. In this way, you can create a single report that will show different results to each user, based on the variable setting in their profile.

This feature is coming soon, and we definitely plan to continue to improve on this in the future. Hope this helps!

Thanks for your patience in this matter,
Ray

Hi Jerome,

From following this thread, I think I see two potential pitfalls which I hope to address here to help you succeed.

Joining data sets in Good Data requires a Source data set and a Target data set. The Target data set, which we call a lookup file or lookup table, should be a data set that contains no facts (no countable numbers). In other words, when uploading a lookup table, all columns should be marked as "Uncountable".

If all columns are marked as uncountable, then at the bottom of the upload screen, the application will ask you to define a "Connection Point." A connection point is the attribute that future data sets will connect with. A connection point should contain all possible values of the connection attribute.

Now in regards to the Source data set, this is what we call a fact table (data set with countable and uncountable columns). The Source data set should contain the connection point attribute contained in the target. The values for the connection point attribute in this Source data set should be a subset of the complete list of values located in the lookup table.

When mapping, it is important to map from the fact table to the lookup table (Source > Target). If the connection point is set during the Source file upload, then this option will be available when mapping. This is the only way to activate options in the right column of the mapping dialog (ie, the only choice available is the active connection point).

A more detailed explanation can be found in the joining data sets tutorial located here:
https://secure.gooddata.com/docs/html...

The key is that all lookup tables can only contain one connection point. However, fact tables can be mapped to multiple lookup tables provided that they contain the appropriate connection attributes.

To explain the second screenshot you sent, it seems as though the attribute used in the Source is part of an already mapped hierarchy. Hierarchies can include Dates or Geographical hierarchies. For example, if a date has already been mapped to the date dimension, then attributes in that dimension (such as Year, Month, Day of Week, etc.), cannot be mapped to something else.

I hope this explains the issue. Please feel free to let me know if you continue having problems with this.

Regards,
Ray

Hi Ed,

Thanks for reporting this! This is clearly a bug, and I will log it in our bug tracker, and hopefully get this resolved quickly.

Thanks again!
Ray