Assume I have two IActorRef pointing to the same actor but obtained from different sources:
One actor reference was obtained during local creation of an actor:
var actorRef1 = system.ActorOf<MyActor>("myActor");
Later this actor reference was passed to a remote actor, and after the same actor reference was returned back (as an actorRef2 for example).
Are the two actor references test for equality?
Object.Equals(actorRef1, actorRef2); // true???
Or another case: two IActorRef were received from different remote systems, and pointing to a same actor on another remote system.
This question was answered via gitter chat. But ill post it here as well for posterity.
IActorRef's are equatable, they are compared via their actorpath and UID. So even if 2 actorrefs are acquired through different means, they will still be equal if they point to the same actor.
Related
I´ve been looking around the Internet for a week trying to discover a useable function that I can use to change a players name in my Plugin, and since most information is waaaaay to old, I was unsuccessful to find anything.
This is what I have tried already:
player.setCustomName(args[0]);
player.setDisplayName(args[0]);
player.setPlayerListName(args[0]);
getConfig().set(player.getName(),args[0]);
Its not like I receive a Error or something, its just that not much happens to the player names (but the function is actually called, I checked).
Simply, you cannot change your full name that you entered in the client settings.
These methods you are trying to use will only change the name of the in-game server for the player object. These also affect the names of the chat, tablist and possibly scoreboard teams. There is a solution that can be used to change the player name for a given player in half, but it will not affect other servers or the client either. Using GameProfile from Mojang, you can change its name and UUID, but this requires creating a new instance and adding it to the existing PlayerInfoData list. If you don't have Spigot/Paper or some software attached to your project, you'll need to use Java Reflections to modify the values/list and everything else, especially in PacketPlayOutPlayerInfo. Or, if you want to avoid Java Reflections, you can use the PlayerProfile interface implemented by Paper, using the Player#getPlayerProfile method.
An example code using Reflections:
Player player = ...; // Your player object here
GameProfile gameProfile = new GameProfile(player.getUniqueId(), "newPlayerNameHere");
// packet is the new instance of PacketPlayOutPlayerInfo
// infoList is the list retrieved from PacketPlayOutPlayerInfo
// playerInfoDataConstr is the PacketPlayOutPlayerInfo constructor
// ping is the amount of ping the player have currently
// gameMode is the EnumGameMode object of the player
// text is the text parsed to IChatBaseComponent
((List<Object>) infoList.get(packet)).add(playerInfoDataConstr.newInstance(packet, gameProfile, ping, gameMode, getAsIChatBaseComponent(text)));
// Send the packet object to every online player on the server
For accessing to GameProfile class you'll need com.mojang.authlib dependency.
Using Paper API is kinda easy to implement.
I have enabled the Cluster Sharding with remember-entities = true. So when I restart my application entities are getting recovered, but I want to know this entity is recovered or it is newly created, any way to get this?
usually, when persitent sharded actor is created it means that it has been initialized at first. I would suggest to create initialization message for new actor, so inside the actor you can easily detect has it been initialized or not. I think akka .net doesn't have something out of box for it.
For example, suppose your AuctionActor receives two messages:
PlaceBid
GetBids
If you ask GetBids for actor with id = x, akka .net will check does it exists in cluster, and create it if not. So, when your actor is started, you can't find out has this auction been started or not. You can create third initialization message:
StartAuction
Then, when GetBids message comes, you can check inside actor has it been initialized or not.
The best example would be an User entity which needs to be persisted. I have the following candidates to assign unique identifier to an user:
Assign keys provided by back-end (NDB, MySQL etc.).
Hand crafting unique identifier through some service (like system clock).
Properties like emailId.
Taking a simple example of a detailed view, we often have a detailed display of an user like some/path/users/{user_id}, if we keep emailId as the unique id then there are chances that an user may change its email id one day and breaks it.
Which is a better approach to identify the same entity?
Named UUID.
UUID, because it gives the identifier a nice predictable structure, without introducing any semantic implications (like your email id example). Think surrogate key.
Named UUID, because you want the generated id to be deterministic. Deterministic means reproducable : you can move your system to a test environment, and replay commands to inspect the results.
It also gives you an extra way to detect duplicated work - what should happen in your system if a create user command is repeated (example: user POSTs the same web form twice). There are various ways that you can guard against this in your intermediate layers, but a really easy way to cover this in your persistence layer (aka in your system of record) is to put a uniqueness constraint on the id. Because running the command a second time produces a "new" user entity with the same id, the persistence layer will object to the duplication, and you can handle things from there.
Thus, you get idempotent command handling even if all of your intermediate guard layers restart during the interval between the duplicated commands.
Named UUID gives you these properties; for instance, you might build the uuid from an identifier for the type of the entity and the id of the command (the duplicated command will have the same id when it is resent).
You can use transient properties of the user (like email address) as part of the seed for your named uuid if you have a guarantee that the property won't ever be assigned to someone else. Are you sure vivek#stackoverflow.com won't be assigned to another user? Then it's not a good seed to use.
Back end key assignment won't detect a collision if a command is duplicated - you would need to rely on some other bit of state to detect the collision.
System clock isn't a good choice, because it makes reproducing the same id difficult. A local copy of the system clock can work, if you can reproduce the updates to the local clock in your test environment. But that's a bunch of extra effort your don't want if time isn't already part of your domain model.
https://www.ietf.org/rfc/rfc4122.txt (Section 4.3)
http://www.rfc-editor.org/errata_search.php?rfc=4122&eid=1352 (Errata for the example in the spec)
Generating v5 UUID. What is name and namespace?
I agree with #VoiceOfUnreason but only partially. We all know that UUIDs are terrible to spell and keep track of. All methods to use incremental and meaningful UUIDs resolve only parts of these issues.
An aggregate is being created with some id that is already available to the creating party. Although UUID can be generated without involving any external components, this is not the only solution. Using an external identity provider like Twitter Snowflake (retired) is an option too.
It is not very complicated to create very simple and reliable identity provider that can return incrementing long value by being given an aggregate type name.
Surely, it increases the complexity and can only be justified when there is a requirement to generate sequential unique numeric values. Resilience of this service becomes very important and needs to be addressed carefully. But it can just be seen as any other critical infrastructure component and we know that every system has quite a few of those anyway.
In my application I have products traveling between stations in a production line. Every pass of the product at a station a result is recorded: success of failure.
The relationship between products and stations is many to many.
If I were programming in a procedural language I would have the following function:
get_last_pass_result($station_id, $product_id) {...}
That returns the result of the last time this particular product passed on this particular station.
Now how would you model this logic in OOP terms?
I would definitely have class station, and class product.
But should I do (php syntax):
$station->get_last_product_pass_result($product_id)
Or
$product->get_last_pass_on_station_result($station_id)
The situation seems symmetric and I wonder what considerations exist do decide between the two (or maybe even some third solution?)
I can't provide here all the existing information about the domain, but feel free to include considerations like: if [an assumption about the domain] then [your design solution], if it feels appropriate
My take, but based on DDD principles, so I don't know it this suits your needs, but anyway...
So you have a Station, and a Product. I would say that they are both entities that can have references to each other, but the logic you are talking about encompasses these entities and could probably be put in a domain service like ProductPassingService with an operation like GetLastPassFor(product, station).
This domain service would have the responsibility to use the underlying domain entities Station and Product (and repositories to query them) and execute the logic that does not belong either to Station and Product. It keeps the entities Station and Product clean of too much responsibility.
Also, domain entities should not use repositories (DDD - the rule that Entities can't access Repositories directly) so this logic belongs in a domain service.
It is not completely clear to me whether the Product represents a type of a product (e.g. a chair) or an individual instance of produce (e.g. chair-001, chair-002). From your example it seem like latter is the case, so I will use that, otherwise get_last_pass_result doesn't make much sense.
I believe that I would introduce a Path type (without knowing lot about the domain, though). Now, depending on other use cases, this might be an aggregate root (in DDD lingo) or not.
This means that it would be accessible via Product instance or directly from DB/repository/whatever. With path instance, I can do simply:
var path = product.GetPath(); // if it is accessible only via product
var path = Path.GetPathForProduct(product); // or pathRepository.GetPathFor(), or ...
var result = path.LastResult;
This approach decouples the factory process from the product itself, and enables some other scenarios (e.g. find average duration, etc...)
As always - it depends on how you'd use it.
But there is a nice "how it works" sample on Discovery channel - an automobile factory. During the journey trough conveyor, an automobile receives more and more additional parts. Each automobile has a kind of job schedule attached - a list of jobs to be done in order to complete the task. While it moves through the line, persons responsible for a job make marks about job completion. So when a defect is found - you know the source for sure.
So, going back to a procedural approach. First, it's more natural to use structure+procedure approach instead of pure oop. But it's up to you, of course.
Second - I'd suggest to separate 'product' from a 'production line log' object, which is in one-to-one relationships with a product, but is not probably necessary for it after the product is released. 'Production line log' stores events related to an object processing by stations. Moreover, you can use it as a schedule, i.e. include instructions how a particular product should be processed (as automobiles to include or not certain features like conditioner or fog lights). And 'planned' action should be marked as 'complete' by a worker.
In nowadays terms it can be also expressed in 'event sourcing' terms: during the movement, product modifications are written into a log; so a product can be re-constructed by replaying modification events one-by-one.
I would suggest to put it in the product. My concern is that the number of product is big, but the stations should be fixed, and it would be natural to record specific product's state in the object of that product. For the station, it may only need to record some statistics.
Working environment: OS X 10.6.3, Xcode 3.2.1
Hi! I'm working on a project called Rent-a-Flick. The project has two entities: Movie and Client. Between them there's a many-to-many relationship.
I have 2 tables: one with the movies and one with the clients. Their content is bound to the proper array controllers(for movie and client).
I want to add a third table in which only the clients that rented a selected movie will appear. I should also be able to add/remove clients from this table. How can I do that without creating duplicates?
The project is open source. I'll publish it as soon as I make a stable release.
This "third table" already exists implicitly in your Core Data many-to-many relationship.
When you call a method like [aMovie addClientObject:aClient] on one of your Core Data model objects, the effect of that is to add a row to the movie-client relationship table. Similarly, if you want to remove a client, you would do it using the Core Data accessor method [aMovie removeClientObject:aClient], not by directly manipulating the table.
If you have an instance of a Movie object, you can see what clients rented that movie simply by referring to the clients property of that object. For example:
NSArray *rented_clients = [[aMovie.clients] allObjects];