|
1 | 1 | This release contains a lot of changes and new features. |
2 | 2 |
|
3 | | -* Updated shapeless to 2.3.3, jawn to 0.8.8, scala to 2.11.7. |
| 3 | +### Updated shapeless to 2.3.3, jawn to 0.8.8, scala to 2.11.7. |
4 | 4 |
|
5 | | - In particular, updating shapeless allowed using picopickle with case classes with variable arguments. |
| 5 | +In particular, updating shapeless allowed using picopickle with case classes with variable arguments. |
6 | 6 |
|
7 | | -* Improved reader interface - added `readOrElse` method and changed existing code to depend on it. |
| 7 | +### Improved reader interface - added `readOrElse` method and changed existing code to depend on it. |
8 | 8 |
|
9 | | - `readOrElse` is borrowed from `PartialFunction` trait where it is called `applyOrElse`. It is an |
10 | | - important method for optimization because it allows checking whether a function (reader) can be |
11 | | - applied to a value and apply it to this value at the same time. Now `Reader` trait has this method |
12 | | - and it is defined and used correctly by the built-in `Reader` combinators, in particular, |
13 | | - for error checks. |
| 9 | +`readOrElse` is borrowed from `PartialFunction` trait where it is called `applyOrElse`. It is an |
| 10 | +important method for optimization because it allows checking whether a function (reader) can be |
| 11 | +applied to a value and apply it to this value at the same time. Now `Reader` trait has this method |
| 12 | +and it is defined and used correctly by the built-in `Reader` combinators, in particular, |
| 13 | +for error checks. |
14 | 14 |
|
15 | | -* Added proper error handling. |
| 15 | +### Added proper error handling. |
16 | 16 |
|
17 | | - While writing data to backend representation is usually an error-free operation (if there is a writer |
18 | | - for some type, it should handle all values of this type), reading data from the backend representation |
19 | | - is a source of errors. This happens because the backend representation has much weaker typing guarantees |
20 | | - than Scala code and can't correspond directly to Scala types. |
21 | | - |
22 | | - Previously picopickle didn't provide any special error handling. If the backend value couldn't be |
23 | | - deserialized, picopickle would throw some obscure `MatchError` or `IllegalArgumentException`. Since |
24 | | - 0.2.0 picopickle has a proper exception system, and if a read error occurs, the exception would contain |
25 | | - much more information about what was expected and what was actually found. You can find more on it |
26 | | - in [Readme][readme-error-handling]. |
27 | | - |
28 | | -* Added new BSON-based backend. |
| 17 | +While writing data to backend representation is usually an error-free operation (if there is a writer |
| 18 | +for some type, it should handle all values of this type), reading data from the backend representation |
| 19 | +is a source of errors. This happens because the backend representation has much weaker typing guarantees |
| 20 | +than Scala code and can't correspond directly to Scala types. |
29 | 21 |
|
30 | | - A new officially supported backend has been added. It uses [MongoDB BSON][mongodb-bson] data types |
31 | | - as the backend representation. |
32 | | - |
33 | | - With this backend it is possible to use picopickle for serialization using the official Mongo drivers. |
| 22 | +Previously picopickle didn't provide any special error handling. If the backend value couldn't be |
| 23 | +deserialized, picopickle would throw some obscure `MatchError` or `IllegalArgumentException`. Since |
| 24 | +0.2.0 picopickle has a proper exception system, and if a read error occurs, the exception would contain |
| 25 | +much more information about what was expected and what was actually found. You can find more on it |
| 26 | +in [Readme][readme-error-handling]. |
34 | 27 |
|
35 | | - It also serves as an example extended backend implementation with more types than the basic backend |
36 | | - supports. |
| 28 | +### Added new BSON-based backend. |
37 | 29 |
|
38 | | -* Added support for changing STH discriminator key on per-STH basis. |
| 30 | +A new officially supported backend has been added. It uses [MongoDB BSON][mongodb-bson] data types |
| 31 | +as the backend representation. |
39 | 32 |
|
40 | | - It is now possible to change sealed trait hierarchy discriminator key for each sealed trait separately: |
41 | | - |
42 | | - ```scala |
43 | | - @discriminator("status") sealed trait Root |
44 | | - case object Stopped extends Root |
45 | | - case class Running(name: String) extends Root |
46 | | - |
47 | | - writeString[Root](Stopped) shouldEqual """{"status":"Stopped"}""" |
48 | | - writeString[Root](Running("me")) shouldEqual """{"status":"Running","name":"me"}""" |
49 | | - ``` |
50 | | - |
51 | | - This allows even more flexibility in defining serialization formats, especially when matching some |
52 | | - existing interface. |
| 33 | +With this backend it is possible to use picopickle for serialization using the official Mongo drivers. |
| 34 | + |
| 35 | +It also serves as an example extended backend implementation with more types than the basic backend |
| 36 | +supports. |
| 37 | + |
| 38 | +### Added support for changing STH discriminator key on per-STH basis. |
| 39 | + |
| 40 | +It is now possible to change sealed trait hierarchy discriminator key for each sealed trait separately: |
| 41 | + |
| 42 | + @discriminator("status") sealed trait Root |
| 43 | + case object Stopped extends Root |
| 44 | + case class Running(name: String) extends Root |
| 45 | + |
| 46 | + writeString[Root](Stopped) shouldEqual """{"status":"Stopped"}""" |
| 47 | + writeString[Root](Running("me")) shouldEqual """{"status":"Running","name":"me"}""" |
| 48 | + |
| 49 | +This allows even more flexibility in defining serialization formats, especially when matching some |
| 50 | +existing interface. |
53 | 51 |
|
54 | 52 | More information can be found in the [readme](https://github.com/netvl/picopickle#readme). |
55 | 53 |
|
|
0 commit comments