I'm working on a legacy mobile application that needs to be synchronized between multiple devices. It uses event sourcing to perform the synchronization. It is an offline application and business logic is executed within the application rather than in a central location. This seems fine since the domain needs to perform business logic is isolated to a group and synchronization happens only between different devices in the same group.
Due to the distributed nature of the system, events that belong to a group (group stream) are ordered by time. Although, existing events are very large and have the following format.
SomethingHappened
{
prop1: {
...props,
created_date,
updated_date,
},
prop2: {
...props,
created_date,
updated_date,
}
created_date // timestamp of the event
}
I'm new to event sourcing and the above format is confusing me. If an event happens at a certain time shouldn't we record it then and there? Is it okay to model events to encapsulate multiple things that happened at different times? If not will this lead to problems in the future?
There's nothing intrinsically wrong with combining multiple events into a single event; it's commonly seen in situations where you want multiple events to be persisted atomically (i.e. all of them get persisted or none of them get persisted). As long as you can be sure that the ordering invariants are being maintained, it's OK.
Related
I have an always one application, listening to a Kafka stream, and processing events. Events are part of a session. And I need to do calculations based off of a sessions data. I am running into a problem trying to correctly run my calculations due to the length of my sessions. 90% of my sessions are done after 5 minutes. 99% are done after 1 hour. Sessions may last more than a day, due to this being a real-time system, there is no determined end. Session are unique, and show never collide.
I am looking for a way where I can process a window multiple times, either with an initial wait period and processing any later events after that, or a pure process per event type structure. I will need to keep all previous events around(ListState), as well as previously processed values(ValueState).
I previously thought allowedLateness would allow me to do this, but it seems the lateness is only considered for when the event should have been processed, it does not extend an actual window. GlobalWindows may also work, but I am unsure if there is a way to process a window multiple times. I believe I can used an evictor with GlobalWindows to purge the Windows after a period of inactivity(although admittedly, I did not research this yet, because I was unsure of how to trigger a GlobalWindow multiple times.
Any suggestions on how to achieve what I am looking to do would be greatly appreciated, I would also be happy to clarify any points needed.
If SessionWindows won't do the job, then you can use GlobalWindows with a custom Trigger and Evictor. The Trigger interface has onElement and timer-based callbacks that can fire whenever and as often as you like. If you go down this route, then yes, you'll also need to implement an Evictor to dispose of elements when they are no longer needed.
The documentation and the source code are helpful when trying to understand how this all fits together.
I have a WPF application that uses entity framework. I am going to be implementing a repository pattern to make interactions with EF simple and more testable. Multiple clients can use this application and connect to the same database and do CRUD operations. I am trying to think of a way to synchronize clients repositories when one makes a change to the database. Could anyone give me some direction on how one would solve this type of issue, and some possible patterns that would be beneficial for this type of problem?
I would be very open to any information/books on how to keep clients synchronized, and even be alerted of things other clients are doing(The only thing I could think of was having a server process running that passes messages around). Thank you
The easiest way by far to keep every client UI up to date is just to simply refresh the data every so often. If it's really that important, you can set a DispatcherTimer to tick every minute when you can get the latest data that is being displayed.
Clearly, I'm not suggesting that you refresh an item that is being edited, but if you get the fresh data, you can certainly compare collections with what's being displayed currently. Rather than just replacing the old collection items with the new, you can be more user friendly and just add the new ones, remove the deleted ones and update the newer ones.
You could even detect whether an item being currently edited has been saved by another user since the current user opened it and alert them to the fact. So rather than concentrating on some system to track all data changes, you should put your effort into being able to detect changes between two sets of data and then seamlessly integrating it into the current UI state.
UPDATE >>>
There is absolutely no benefit from holding a complete set of data in your application (or repository). In fact, you may well find that it adds detrimental effects, due to the extra RAM requirements. If you are polling data every few minutes, then it will always be up to date anyway.
So rather than asking for all of the data all of the time, just ask for what the user wants to see (dependant on which view they are currently in) and update it every now and then. I do this by simply fetching the same data that the view requires when it is first opened. I wrote some methods that compare every property of every item with their older counterparts in the UI and switch old for new.
Think of the Equals method... You could do something like this:
public override bool Equals(Release otherRelease)
{
return base.Equals(otherRelease) && Title == otherRelease.Title &&
Artist.Equals(otherRelease.Artist) && Artists.Equals(otherRelease.Artists);
}
(Don't actually use the Equals method though, or you'll run into problems later). And then something like this:
if (!oldRelease.Equals(newRelease)) oldRelease.UpdatePropertyValues(newRelease);
And/Or this:
if (!oldReleases.Contains(newRelease) oldReleases.Add(newRelease);
I'm guessing that you get the picture now.
So I am running into an issue with where i need to divide my users into segments in Apsalar but it's based off of one event
The event only happens when running in debug (so testers), and while i can still make a segment for them in Apsalar i will run into the issue where testers have their events mixed in with players
The end result of this is that tester data and player data are separate and I keep track of both.
I can do this with Flurry because they allow me to segment based on NOT having an event, but I was wondering if there was a way to do something similiar with Apsalar?
To accomplish your goal - separating tester data from player data - I recommend creating a unique application from within the Apsalar dashboard.
Doing so will allow you to divide your events, segments, cohorts, and other application data into two clear buckets on Apsalar's platform. I believe it is better to ensure you are not duplicating the data you are reporting and analyzing in Apsalar than to create an event based on the absence of an event. If you create multiple segments based on NOT having an event, I guarantee it will be difficult to parse which segments belong to your testing and production purposes.
Let me know if this helps.
Image URL:
http://ge.tt/4tJJSJR/v/0
Suppose my WinForms application has a business entity Order, the entity is used in multiple views, each view handles a different domain or use-case in the application. As an example, one managing orders, the other one digging into one order and displaying additional data.
If I'd use nHibernate (or any other ORM) and use one session/dataContext per view (or per db action), I'd end up getting two different instances for the same Order (let's say orderId = 1). Although functionally the same entity, they are technically two different instances. Yes, I could implement Equals/GetHashcode to make them "seem" the same.
Why would you go for a single instance per entity vs private instances per view or per use-case?
Having single instances has the advantage of sharing INotifyPropertyChanged events, and sharing additional (non-persistent) data.
Having a private instance in each view would give you the flexibility of the undo functionality on a view level. In the example above, I'd allow the user to change order details, and give them the flexibility to not save the change. Here, synchronisation between the view/use-case happens on a data persistence level.
What would your argument be?
You should implement Equals/GetHashCode methods. This is a recommended practice when using ORMs.
In addition, you should typically stick with the "One View, One Session" mantra. Persist all of your objects when your view changes or loses focus. If you really need to share entities across views... well do it! Sometimes you must.
And once again, because when we are looking at the business objects from an entity and row type of perspective, we should not be concerned with "object" level equality.
I can't speak for ORM's, but I think you answered your own question - to an extent. You've provided pros and cons for both options: neither is right or wrong in absolute terms.
The options are only right or wrong depending on your situation. If sharing info makes sense use single-shared instance, but if the ability to undo is more important use multiple / private instances.
You might have other concerns which drive the decisions too: think about the NFR's (or "illities") and the context of the system. For example, if performance is a key concern and you know you're going to have large user bases then that might help suggest one option over the other, or force you to re-think it again from scratch.
Finally - you have "order", what about other entities - how are they being handled?
Or, if you don't have any, what will happen when/if you do? Would that have any imapct on your architecture?
I have a collection of "active objects". That is, objects that need to preiodically update themselves. In turn, these objects should be used to update a WPF-based GUI.
In the past I would just have each object include it's own thread, but that only makes sense when working with a finite number of objects with well-defined life-cycles. Now I'm using objects that only exist when needed by a form so the life cycle is unpredicable. Also, I can have dozens of objects all making database and web service calls.
Under normal circumstances the update interval is 1 second, but it can take up to 30 seconds due to timeouts.
So, what design would you recommend?
You may use one dispatcher (scheduler) for all or group of active objects. Dispatcher can process high priority tasks at the first place then other ones.
You can see this article about the long-running active objects with code to find out how to do it. In additional I recommend to look at Half Sync/ Half Async pattern.
If you have questions - welcome.
I am not an expert, but I would just have the objects fire an event indicating when they've changed. The GUI can then refresh the necessary parts of itself (easy when using data binding and INotifyPropertyChanged) whenever it receives an event.
I'd probably try to generalize out some sort of data bus, if possible, and when objects are 'active' have them add themselves to a list of objects to be updated. I'd especially be tempted to use this pattern if the objects are backed by a database, as that way you can aggregate multiple queries, instead of having to do a single query per each object.
If there end up being no listeners for a specific object, no big deal, the data just goes nowhere.
The core updater code can then use a single timer (or multiple, or whatever is appropriate) to determine when to get updates. Doing this as more of a dataflow, and less of a 'state update' will probably save a lot of sanity in the end.