All Versions
26
Latest Version
Avg Release Cycle
131 days
Latest Release
1933 days ago

Changelog History
Page 1

  • v1.0.0-M9 Changes

    January 08, 2019

    🚀 In this release, new effect modules have been added for cats-effect, scalaz and scalaz-zio 🎉

  • v1.0.0-M6 Changes

    March 29, 2018
    • Aggregate scanamo-refined in the root project (#194)

  • v1.0.0-M5 Changes

    March 16, 2018
    • Add getAllWithConsistency (#184 - @Slakah)
    • Add support for refined types in scanamo-refined submodule (#182 - @alonsodomin)
    • Improve documentation (#193 and #190 - @howardjohn and @philwills)
    • Allow append/prepend of list values (#187 - @prurph)

  • v1.0.0-M4 Changes

    January 08, 2018
    • Update cats to 1.0.1
    • Update shapeless to 2.3.3
    • Update aws-java-sdk-dynamodb 1.11.256
    • Update scalatest to 3.0.4
    • Update scalacheck to 1.13.5
    • Update travis badge to reflect org move

  • v1.0.0-M3 Changes

    November 14, 2017
    • Update Cats to 1.0.0-RC1 (#166)
    • Equals condition support for nested attributes (#165 - @ivashin)
    • Update aws-java-sdk-dynamodb and alpakka (#167)

  • v1.0.0-M2 Changes

    • Add support for Alpakka as a client (#151 - @btlines), plus docs (#158 - @calvinlfer)
    • Return overwritten item from Put (#153 - @amirkarimi)
    • BigDecimal support (#161 - @hunzinker)
    • Support conditions on nested attribute names (#156)
    • Rename Index to SecondaryIndex (#144)

  • v1.0-M13 Changes

    October 05, 2020

    Hey folks.

    🚀 Loads happened since last milestone release and my apologies to those who have been waiting. In February, I left the Guardian for pastures new and have since had zero motivation to work on this project. In fact I took no pleasure in working to this project, and the lack of people from the Guardian contributing has not been encouraging. So, this will be my last release, I take much more pleasure in other projects that I had to leave aside for this one. The highlights in this release are mostly syntactic, but since this is the only selling point for this library, I think they are important.

    🗄 Deprecating tuple syntax

    👀 The API has not aged well, I feel. Among others, the weird syntax for key equality conditions, which perhaps made sense when the library was created, is not something you would see in other recent libraries. So, this is gone:

    table.get(key -\> value)

    and instead I've introduced an operator very similar to Slick's own:

    table.get(key === value)

    Same for key IN (value1, value2, ..., valueN) conditions. Gone is

    table.getAll(key -\> Set(value1, value2, ..., valueN))

    welcome

    table.getAll(key in Set(value1, value2, ..., valueN))

    Ultimately I think both should go anyway and be reduced to:

    table.get(value) table.getAll(value1, value2, ..., valueN)

    as the key for a table or secondary index should be defined once, at the creation site.

    ➕ Add support for CONTAINS queries

    You can now filter for rows where an attribute contains a substrings, just like that:

    table.filter(attribute.contains("substring")).scan

    👌 Improved BETWEEN queries

    You should be able to just write

    table.filter(attribute between value1 and value2).scan

    which previously was unsightly:

    table.filter(attribute between (value1 and value2)).scan

    🍱 🤮

    ⬆️ Upgrade to AWS SDK v2 🎉

    🚀 You're welcome. It also allowed me to remove all the retry logic that was added for the alpakka interpreter in the previous release.

    First shot at transactional APIs

    ⚡️ The great @rmckirby was kind enough to contribute transactional updates and deletes, given by the folowing APIs:

    table.transactUpdateAll(List( key1 -\> update1, key2 -\> update2, ..., keyN -\> updateN )) table.transactDeleteAll(List(key1, key2,..., keyN))

    Ultimately, a transaction crosses table boundaries so a bespoke abstraction should be added, e.g.

    (table1.update(key, update) \>\> index2.delete(key) \>\> table3.put(key, value)).transactionally

    👌 Improve semi auto-derivation

    The first release of Magnolia-based derivation worked a bit too well, as it automatically derived all types involved in semi auto-derivation. Now, the compiler will report an error, which is the expected behaviour.

    ⬇️ Drop support for Scala 2.11

    Sorry if you're stuck with that version, but it was starting to become problematic, esp. as Magnolia was adopted.

    Too many @scala-steward contributions to count

    This is such a valuable project, everyone should use it in their own environment, even as a standalone installation.

  • v1.0.0-M12 Changes

    January 23, 2020

  • v1.0.0-M11 Changes

    September 22, 2019

    Notable changes

    There are a couple of breaking changes that must happen now that we don't really care about binary/source compatibility.

    No more Symbol

    🔨 Scanamo used to heavily rely on symbols in its DSL: table.get('id -> 123). The syntactic sugar has always been problematic in IDEs, that's why it is going away in the next Scala version, and will probably be replaced with something like sym"id"; at which point it becomes a nuisance in our DSL. So I've removed them in favour of simple strings: table.get("id" -> 123). They get exactly the same treatment and are still quite limiting. In an upcoming version, AttributeName will be refactored to support the full breadth of expression supported by DynamoDB, and a custom string context will be provided, provisionally a"My.Array[$i].$SubProperty".

    Streaming in constant space

    This has been bugging me for long and many users have complained about the fact that table.scan will load the full result set in memory, even if one only needs to ever process a subset of results. There are now four new APIs in table: scanM, scanPaginatedM, queryM and queryPaginatedM which will load one subset at a time. The return type is slightly different than the other APIs: ScanamoOpsT[M, List[Either[DynamoReadError, T]]].

    The M type parameter identifies an underlying monad that has additional capabilities given by the MonoidK constraint: lazy streams such a ZStream from the ZIO library are one example, so you could write something along the lines of table.scanM[Stream[AmazonDynamoDBException, *]]. You can mix "regular" API calls with these ones in the same computation; all you have to do is lift them, for example:

    val ops = for { \_ \<- items.putAll(list.toSet).toFreeT[Iterant[IO, \*]] list \<- items.scanPaginatedM[Iterant[IO, \*]](1) } yield list

    In order to interpret your program, use the client.execT function which takes two parameters:

    • hoist: IO[AmazonDynamoDBException, *] ~> M which lifts an effect into the destination monad
    • op: ScanamoOpsT[M, A] your program

    I wrote some obvious versions of hoist for:

    • ScanamoZio.ToStream for ZStream (ZIO)
    • ScanamoCats.ToIterant for Iterant (Monix)
    • ScanamoCats.ToStream for Stream (FS2)

    The above example can be interpreted with client.execT(ScanamoCats.ToIterant)(ops).

    I haven't used this extensively yet, so any feedback on that new feature will be greatly appreciated.

    0️⃣ Removal of DynamoFormat[A].default

    DynamoFormat is a typeclass witnessing that your type can be encoded/decoded to/from a fancy JSON value. However, DynamoDB comes with some idiosyncratic restrictions wrt the values that it will accept or not in some APIs. For instance, empty strings are forbidden. These peculiar rules have nothing to do with the JSON encoding, they are an implementation detail that leaks into DynamoDB APIs. Besides, it only ever affected a very strict subset of all the types for which there is a DynamoFormat instance, all of which are defined in the library.

    0️⃣ The default member of DynamoFormat was created to solve that problem, where e.g. during decoding if a value is supposed to be a string and it is missing, we can produce the empty string in its stead. There is another way to do exactly that without having to pollute the API, and that's what I've done. You shouldn't notice any difference, as it is unlikely that default ever leaked into your code, but that simplification allows for future improvements.

    👌 Improvements to the retry policy for the Alpakka interpreter

    🚀 The previous release introduced the ability to control the behaviour of scanamo whenever an error occurs in DynamoDB, using the alpakka interpreter. While the DSL is sound, its interpretation was flawed in several ways 😅. These issues have all been addressed now.

    👍 Working on this, I realised other interpreters delegate a lot to the underlying DynamoDB client without much fanfare. I think we should not use these clients at all—they're just fancy HTTP clients—so that we can better control the behaviour in case of errors and be consistent across interpreters.

    ⚡️ Updates

    By contributors

    By @scala-steward

    • ⚡️ Update akka-stream-alpakka-dynamodb to 1.1.1 #478
    • ⚡️ Update cats-core, cats-free to 2.0.0 #503
    • ⚡️ Update cats-effect to 2.0.0 #504
    • ⚡️ Update fs2-core to 2.0.1
    • ⚡️ Update joda-time to 2.10.4 #512
    • ⚡️ Update monix to 3.0.0 #506
    • ⚡️ Update refined to 0.9.10 #508
    • ⚡️ Update sbt to 1.3.2 #513
    • 🚀 Update sbt-ci-release to 1.3.2 #510
    • ⚡️ Update sbt-doctest to 0.9.5 #437
    • ⚡️ Update sbt-scalafmt to 2.0.5 #509
    • ⚡️ Update sbt-scoverage to 1.6.0 #439
    • ⚡️ Update scalacheck-toolbox-datetime to 0.2.6 #487
    • ⚡️ Update scalafmt to 2.0.1 #483
    • ⚡️ Update scalatest to 3.0.8 #431
    • ⚡️ Update tut-plugin to 0.6.12 #427
    • ⚡️ Update zio, zio-streams to 1.0.0-RC12-1 #498
    • ⚡️ Update zio-interop-cats to 2.0.0.0-RC3 #499

    Coming next

    🚀 The next release will be the last one before a first release candidate. First?! Hmm, I may have lost count 😅

    • 👍 Better package organisation: the scanamo package makes implementation decisions on the user's behalf. Instead, I plan on moving the core library features into scanamo-core, the generic derivation into scanamo-generic and the interpreters into sub-packages as they are now.
    • Shapeless will be replaced with Magnolia for derivation; this should speed up compilation substantially. My initial experiment failed because I couldn't find a way to handle automatic derivation properly, but I found a solution for that.
    • Separate encoders and decoders, as many apps only require one of them. That will also give us the flexibility to make manual encoding a breeze, easy enough that people can avoid using scanamo-generic most of the time.
    • Condition expressions can be encoded using an initial encoding, rather than going through the current implicit machinery. This will make the API cleaner and also more scalable.
    • Some more API cleanup: some operations can return values, this is an opt-in feature of DynamoDB. At the moment operations like put make a decision that may not fit everyone, so I'm relaxing that constraint and generalising the API.
    • 📚 Documentation: the website publishing process is kind of broken and as a result its content has drifted from the most recent API changes. This has confused more than one user, me included. We need to fix this once and for all, so it doesn't happen again.

  • v1.0.0-M10 Changes

    May 24, 2019