Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Age Mooij
@agemooij
In other words:
resolvers += "Sonatype Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots/"
followed by:
libraryDependencies += "com.scalapenos" %% "stamina-json" % "1.10-SNAPSHOT"
Joost
@jheijkoop
I think you mean 0.1.1-SNAPSHOT
I updated my example app to now use the snapshot release version: https://github.com/jheijkoop/akka-persistence-stamina-example
Dan Brooke
@kiequoo
I think the whole json versioning aspect of this project is very interesting also outside of the context of akka-persistence. For instance we are sending json objects over RabbitMQ and it would be awesome for the different producers to be able to send different versions and the consumer to be able to easily convert any previous version to the latest. I only had a quick look at the code but it doesn't look like it would be super complicated to split the akka parts from stamina-core into a stamina-akka module. Does anybody else think this is an interesting idea and worth pursuing?
Age Mooij
@agemooij

@kiequoo Thanks. We have discussed that idea before but so ar we have been afraid to go too generic before we have a good solid first release that fits our core use case. I agree that the same techniques could be used in other contexts.

We have been moving towards separating the key/version metadata from the raw serialized data, using Akka 2.4's new SerializerWithStringManifest. As part of that (currently a PR under review) we could more easily allow other tools to get the manifest as a separate artifact of serialization. In your specific case you would have to then combine the manifest with the serialized data into a message to sent over RabbitMQ. Does that make sense? If so, please have a look at scalapenos/stamina#29 and let us know whether that would be usable already of whether it needs more separation of concepts.

Bekir Oguz
@bekiroguz
Hi guys, we are considering to use stamina in our akka-2.4 project with a cassandra backend, is it already 'advised!' to use stamina with akka 2.4? We would like to give it a try if there are no known major issues.
Age Mooij
@agemooij

@bekiroguz There are no known issues with Akka 2.4, although we are (very slowly) working on better, more native support for 2.4-specific features so it's highly likely that the first official release of Stamina will be 2.4-only.

Our (and perhaps your) biggest problem is lack of capacity/free time to really push a public release out the door. Stamina is a pretty small, focused library built around a simple core idea and it is definitely usable in production but, even though I would love for you to start using it, I do have to warn you that we don't have a lot of available time to add new features at this point. On the other hand, some more active users that provide good feedback, issues, etc would certainly help get us to 1.0 faster :smile:

James Delaney
@tddevangelist
Hi. We are very interested in using this product in production. Do you have a rough idea of when the first official release will happen?
Age Mooij
@agemooij

@ldhardy hi there. It's been languishing a bit due to lack of time to spend on the project. The main things that still need to be done before a major release can be made is to finish the move to Akka 2.4 and the new String based serializer. I hope to spend time working on that this coming week but I can;t promise anything.

That said, does Stamina as it stands now have enough features for you to start using it? We have been publishing snapshot releases. Have you been working with those already?

James Delaney
@tddevangelist
We haven't yet. I plan to get it imported to our network this week.
Age Mooij
@agemooij
I suggest you get a feel for things using the latest snapshot release while we work on the finishing touches. Everything is production ready and has been battle tested, it;s just that we didn't want to release it for an outdated version of Akka, hence the small backlog to still cover.
James Delaney
@tddevangelist
Ok. I'm sure I can convince them to at least try the snapshot. I might need to give them an estimate of when it might be production ready to convince them. If not until 2017, we might have to go down another path for a while. Thanks for the quick response.
Age Mooij
@agemooij
It's going to be between now and April, if not sooner.
Calvin Lee Fernandes
@calvinlfer
Looking forward to it :smile:
Calvin Lee Fernandes
@calvinlfer
hey guys, hows it going :)
Arnout Engelen
@raboof
Things are going pretty well ;)
we released 0.1.1 a while back, and while there's still a lot of ideas for future work, we're quite happily using it in production
we still expect some changes in the DSL, so we're not ready to declare source-compatibility (let alone binary compatibility), but your persisted data is safe
which seems OK, as stamina is unlikely to be a transitive dependency anyway
Calvin Lee Fernandes
@calvinlfer
Will you be incorporating event adapters into the design?
Arnout Engelen
@raboof
I did an experiment with hooking in via event adapters (scalapenos/stamina#36), I'm basically awaiting feedback on that ;)
likely we'll support both (via event adapters and via serialization) in the future
Calvin Lee Fernandes
@calvinlfer
:+1:
Nick Childers
@Voltir
It appears that the 0.1.1-SNAPSHOT is no longer published to sonatype?
Arnout Engelen
@raboof
@Voltir it could be sonatype cleans up snapshots - do you have any reason not to move to 0.1.1?
Nick Childers
@Voltir
im not sure where 0.1.1 is published?
Arnout Engelen
@raboof
@Voltir it's on maven central: http://search.maven.org/#search%7Cga%7C1%7Cstamina - should be available by default in sbt
(you can also download it from https://github.com/scalapenos/stamina/releases but I'm not sure why you'd want to :) )
@Voltir I've updated the README for a bit, let me know if you run into any further challenges!
Giampaolo Trapasso
@giampaolotrapasso
Hi there
Is 0.1.1 production ready?
Age Mooij
@agemooij
It is used in production with at least one company that I know of and they have never had any problems. the low version number is more about leaving room for API changes then about stability or production readiness. Stamina is basically a version 3.0 of an older, closed source idea that is also running in production (for about 1.5 years already).
Giampaolo Trapasso
@giampaolotrapasso
thanks for the explanation
Akos Krivachy
@krivachy
Thought it would be better to ask here than in an issue: is there any way to guarantee at compile time that all objects that I call persist and persistAll with will be serializable by stamina? I'm looking to provide this guarantee as we'll probably be maintaining this code for a while so being sure that the events we persist are upgradeable would be quite important. Have any of you implemented nice strategies for something like this?
Age Mooij
@agemooij
Well, that depends a bit on the implementation. The stamina-json implementation enforces this at compile time by requiring an implicit json format type class and explicit json transformers but of course in the end you will still have to unit test your AST transformations becuase those are untyped by nature.
Or am I misinterpreting your question?
Akos Krivachy
@krivachy
Yes, I was more thinking about solving the unsealedness of the Persistable trait :) Not an easy thing to solve. But essentially I can easily imagine someone adding an Event that needs to be persisted, but doesn't implement the required persister/format for it.
Age Mooij
@agemooij
Yeah, the untyped nature of Akka's serialization system puts this outside the reach of Stamina. The best we can do is to make it as easy and safe as possible to work around that core limitation.
Arnout Engelen
@raboof
@krivachy indeed forgetting to implement a persister is a risk
Arnout Engelen
@raboof
@krivachy I think there are 2 failure modes here: adding an event that implements Persistable but forgetting to support that class in your persister, and forgetting to make it Persistable at all
@krivachy the former quickly comes up during testing, as it would fail as soon as you try to persist the first event of that type
@krivachy the second is more tricky: by default akka would fall back to Java serialization, and you might not notice until it's basically too late
@krivachy I'd like to extend stamina-testkit so it could check you've covered all your event types (perhaps using a macro?), that might also help you catch the former situation earlier
Arnout Engelen
@raboof
@krivachy for the second situation you could try disabling the standard Java serializer altogether, but that might be cumbersome if you're also using it in other places (e.g. for akka-remoting) :)
@krivachy eventually I'd like us to be able to configure akka-persistence and akka-remoting serializers separately (and don't use Java serialization by default for akka-persistence) - but that'd probably require a change to upstream akka-persistence
Age Mooij
@agemooij
@raboof I talked to someone on the Akka team yesterday and the new remoting stuff being designed at the moment should be able to solve this. They are mostly unaware of this problem AFAIK so I suggest creating some issues targeted at the new remoting preview to get the conversation started.
The project is called Artery. Here's the original issue: akka/akka-meta#16
Leonard Ehrenfried
@leonardehrenfried
@raboof @agemooij I've written a persister implementation that uses play-json instead of spray-json. would you be interested in merging this code in or do you think it would be better off in its own repository?
Arnout Engelen
@raboof
@leonardehrenfried I think it'd indeed make sense to have it as a subproject inside of stamina - it's probably fairly small (right?), and having it follow the stamina release cycle would be convenient. @agemooij agree?