Skip to main content

5 posts tagged with "General"

· One min read

  • The Console now displays a descriptive message when trying to delete a Data Pool that has Metrics attached
  • The Console now displays a descriptive message when trying to delete a Metric that has an access policy attached.
  • Password reset flow now works.
  • The Console now returns to the last environment the user was in vs. defaulting to the prod environment.
  • You can now re-order dimensions on Boosters to sort the most commonly used dimensions first.
  • Added suggestedDataPoolColumnType and supportedDataPoolColumnTypes to the Column object in the GraphQL schema.
  • Average, Minimum, and Maximum Metrics will now return nullfor “no data”, rather than zero. This is the mathematically correct answer. This applies to counters, time series, leaderboards, reports, and dimension stats.
  • Signup emails sent from Propel in response to signups, etc., will now arrive from a ”mail.propeldata.com” MAIL FROM address.
  • Fixed an issue with pending DataPools that caused mismatches between DataSource columns and DataPool columns.
  • We are no longer exposing stack traces in GraphQL error responses.
  • Fix to correctly handle TIMESTAMP_TZ and TIMESTAMP_LTZ columns when syncing Snowflake Data Pools. This issue led to no Syncs being created for these Data Pools.
· One min read

Today we are thrilled to announce Propel's AWS S3 Data Source connector. The AWS S3 Data Source enables you to power your customer-facing analytics from Parquet files in your AWS S3 bucket. Whether you have a Data Lake in AWS S3, are landing Parquet files in AWS S3 as part of your data pipeline or event-driven architecture, or are extracting data using services like Airbyte or Fivetran, you can now define Metrics and query their data blazingly fast via Propel's GraphQL API.

Read the blog post: Introducing the AWS S3 Data Source: Power customer-facing analytics from Parquet files in your S3 bucket.

· One min read

Today, we are thrilled to introduce Propellers, an easy way for product development teams to select the optimal cost and query speed for their customer-facing analytics use cases.

Propellers are the unit of compute in Propel. The larger the Propeller, the faster the queries and the higher the cost. Every Propel Application (and therefore every set of API credentials) has a Propeller that determines the speed and cost of queries.

Read the blog post: Introducing Propellers: Easily select the optimal cost and query speed for each use case

· One min read

Application scopes allow your client- or server-side app to access Propel resources. We’re now offering you greater control in restricting what an Application can or cannot do on your app’s behalf with OAuth 2.0 scopes.

Your app can request the following scopes:

  • admin — The Application has read/write access to Data Sources, Data Pools, and Metrics within its Environment.
  • metric:query — The Application can query Metrics within its Environment.
  • metric:stats — The Application can query Metrics’ Dimension Statistics within its Environment.

When generating an access token for your app, you can choose which of these scopes to include. The example below uses curl to generate an access token with only the “metric:query” and “metric:stats” scopes. This ensures the generated access token can only query Metrics and Dimension Statistics, perfect for securing customer-facing apps.

curl https://auth.us-east-2.propeldata.com/oauth2/token \
-d grant_type=client_credentials \
-d client_id=$APPLICATION_ID \
-d client_secret=$APPLICATION_SECRET \
-d 'scope=metric:query metric:stats'

Applications can use any of the available scopes.

· One min read

  • You can now reconnect a Data Source if a connection failed.
  • You can now introspect tables in a Data Source to get the latest tables and schemas.
  • You can now see the query activity on the Metric detail page.
  • The Dashboard now shows top queries by Applications and Metrics.
  • You can now see the unique values for a Metric Dimension.