Changelog From v1.3.0 To v1.3.1

• created by @gburgett

Changelog From v1.2.1 To 5bece58cc24bd7241c8c2de15469044badd98ce0

fixes #266

I found that in our Rails apps in Develop, we had frequent deadlocks which were showing up as long times to render views. I'm still not 100% sure how the deadlocks happened, but I am 100% confident that this new code is still thread safe.

Incidentally I also fixed #264 by injecting a logger from the configuration into the postgres store.

Issues closed in this release:

No Milestone

• #266 Sync engine starts over from page 1 every time
  • created by @gburgett
• #264 Make sure PostgresStore has a logger
  • created by @gburgett

Changelog From v1.2.0 To 9f5873c4ddeafd23e39b18af96d69e50d318d244

• Implements an exponential backoff algorithm for the sync engine job, with configurable parameters.

The Contentful CDN aggressively caches content, and it often happens that a Webhook will be sent and processed before the Sync API is able to provide the new content. This results in a Sync that does not include the entry indicated in the webhook (passed to the job via the up_to_id parameter.) In this case, the following lines appear in the logs, and the job is re-enqueued for 10 minutes later (Changed to 10 seconds in 2bc755a, not yet released)

INFO -- : [ActiveJob] [WCC::Contentful::SyncEngine::Job] [8447dd93-0be7-49e9-a7fb-66804f4a3fa4] WCC::Contentful::Event::SyncComplete
INFO -- : [ActiveJob] [WCC::Contentful::SyncEngine::Job] [8447dd93-0be7-49e9-a7fb-66804f4a3fa4] Synced 0 entries.  Next sync token:
  FEnCh...
INFO -- : [ActiveJob] [WCC::Contentful::SyncEngine::Job] [8447dd93-0be7-49e9-a7fb-66804f4a3fa4] Should enqueue again? [true]

10 minutes is far too long a time to wait. This PR more agressively hits the Sync API to try to catch the CDN update as soon as possible. Now, if the changed entry is not present on the Sync API yet, the SyncEngine::Job will retry after 1 second, then 2 seconds, then 4 seconds, for a total of 4 attempts over 7 seconds before giving up.

• Upgrades Rubocop to the latest 1.x version
• Responds to new cops
• Marks gem's required ruby version as >= 2.7 (Support for < 2.7 was dropped in v1.2.0)

This gem is using an outdated version of the GraphQL gem and is no
longer useful. If we want to reconstitute it, we should re-write it
from scratch using the latest version of the GraphQL gem.

Issues closed in this release:

• • created by @

Changelog From v1.1.2 To v1.2.0

Added support for Ruby 3 and Rails 6

This PR builds out an object model for initial RichText support.
The goals for this PR:

• Prevent "unknown field type RichText for field body"
• Allow RichText users to iterate RichText data w/ basic hash methods [] and dig
• Provide a base Object Model on which we can build more features without introducing breaking changes

refs #260

Previously, the SimpleClient response would memoize each page, constructing a linked list of all the pages. For large spaces this means that by the final page, the entire space is held in memory at once.

This PR breaks the linked list, so the lazy iterator runs through each page one at a time and resolves includes within the context of each page. This should allow the garbage collector to clean up past pages, reducing memory pressure.

Issues closed in this release:

No Milestone

• #260 unknown field type RichText for field body (ArgumentError)
  • created by @imanpalsingh

Changelog From v1.0.0 To v1.0.1

fixes #242

Issues closed in this release:

No Milestone

• #242 Postgres store can't do find_by equality check on numeric values
  • created by @gburgett

Changelog From v1.0.7 To v1.0.8

refs #https://github.com/watermarkchurch/paper-signs/issues/2639

Extracted markdown method into its own class. So it can be used independently in other apps.

Created a MarkdownRenderer class for use in jtj-com.

Part of watermarkchurch/jtj-com#434

Issues closed in this release:

• • created by @

Changelog From v1.0.8 To v1.1.0

This PR enables an app to create a Model layer in a separate Namespace (i.e. not under WCC::Contentful::Model). This allows us to create a second Stack of Model -> Store -> Client to access a completely separate space within the same ruby process.

The intent is that all recursive link resolution code should pull from the same Store where the original model came from. Calling .find or .find_by on a model class should pull it from the correct space based on the Namespace.

The use case is to enable us to implement Papyrus inside of Paper Signs with an independent Contentful connection to the Papyrus space.

fixes #250

Example usage:

# lib/papyrus/model.rb
class Papyrus::Model
  include WCC::Contentful::ModelAPI

  configure do |config|
    config.schema_file = 'db/papyrus-contentful-schema.json'
  end

end

# config/initializers/papyrus.rb
Papyrus::Model.configure do |config|
    config.space = '1234'
    config.access_token = 'xxxx'
end

Issues closed in this release:

No Milestone

• #250 Allow creating models from another space
  • created by @gburgett

Changelog From v1.1.0 To v1.1.1

Allow specifying an explicit webhook route

Needed for https://github.com/watermarkchurch/paper-signs/pull/2729
Usage:

      WCC::Contentful::WebhookEnableJob.set(wait: 10.seconds).perform_later({
        management_token: config.management_token,
        space: config.space,
        environment: config.environment,
        default_locale: config.default_locale,
        connection: config.connection,
        webhook_username: config.webhook_username,
        webhook_password: config.webhook_password,

        # The webhook is mounted under the "papyrus" namespace
        receive_url: URI.join(config.app_url, 'papyrus/webhook/receive').to_s,
      })

Support the :in operators on CDN Adapter

This is required for https://github.com/watermarkchurch/paper-signs/issues/2702 and https://github.com/watermarkchurch/paper-signs/issues/2703
In order to resolve Properties that link to the blog post's Categories, I want to execute this query within a blog post:

Papyrus::Property.find_all(
  categories: { id: categories_ids }
)

which should result in a query similar to this:

https://cdn.contentful.com/spaces/xxxxxx/entries?content_type=property&fields.categories.sys.id%5Bin%5D=3snRTIDPQFaAUiLda3QdTc,63V41sK2c5lXhKv3y7bZnH&include=0

I have confirmed that the above query results in the correct data via the Contentful CDN

Issues closed in this release:

• • created by @

Changelog From v1.1.1 To v1.1.2

Fixes a bug where two namespaces were sharing the same registry.

The symptom was that a paper-signs Page was instantiating a Papyrus::PageMetadata, because the WCC::Contentful::Model registry was in fact the same ruby hash as the Papyrus::Model registry. So, when the Papyrus::PageMetadata class got eager-loaded, it triggered the included hook which put it in the registry, and then the Paper Signs PageMetadata never got loaded.

Issues closed in this release:

• • created by @

Release v0.4.0-beta