The JavaDoc for EntityProxy.stableId() says:
"An id returned by a proxy newly created by RequestContext.create
Object.equals(Object) those returned later by proxies to the persisted object."
Does that mean that the stable id will be valid for that object across different request contexts? across different request factory instances? I suppose I'm asking what is the scope of the stable id?
The EntityProxyId object has a global scope and is suitable for long-term use as a Map key or member of a Set. EntityProxyId objects can be used across different instances and types of a RequestFactory (assuming that the proxy type is reachable from the RequestFactory in question). The RequestFactory.getHistoryToken() and getProxyId methods can create a string representation of an EntityProxyId that is suitable for client-side persistence.
The one exception to the global scope of an EntityProxyId is the id of a newly-created EntityProxy that has not yet been persisted on the server. An "ephemeral" id is only usable with the RequestFactory from which the newly-created proxy object is derived. Once the proxy has been sent to the server and the server has provided a non-null id, the ephemeral id is upgraded to a persistent id and becomes indistinguishable from any other persistent id. The object identity of the upgraded EntityProxyId does not change, so ephemeral ids can be added to Map or Set and be retrieved later.
Related
Can a Orion Context Broker entity have two attributes with the same name but different type?
If yes, is it controlled by Orion? Is an error returned when such an entity is created?
If no, what happens when a convenience operation tries to get the value of one of the 2 attributes (AFAIK, the attribute type is not passed in the operation).
From Orion 0.17.0 on, type is no longer used to identify an attribute. Thus, attributes are identified by name plus (optionally) metadata ID. I will assume version >=0.17.0 in the rest of this answer.
Orion doesn't control violation of that rule when processing operations to create entities or append attribute on existing entities. In those cases, only one instance of the attributes with the same identification is taken an stored in the DB, the others are ignored. It is not recommended at all that a client do such kind of operations (in the future, Orion may check that condition and return an error to the client).
Taking account the above paragraph and regarding what happens when a convenience operation tries to get the value of one of the 2 attributes (AFAIK, the attribute type is not passed in the operation)? note that situation cannot happend. I mean, at Orion DB will never store two attributes with the same identification associated to the same entity.
Some additional comment regarding metadata ID: I don't recommend the use of metadata ID as any potential ID can be included in the name and you will get your client much simpler, e.g. you don't need and attribute with name=temperature and id=outside if you use name=temperature::outside or any other namespacing technique.
So far i understand that i will have no more need to define an #version field in my entitites and no more need to use an entity locator. And for value proxies i will have to usenormal editors. Any other diffrences, advantages, disadvantages? What about in the context of using request factory in conjunction with spring
The main difference is that with EntityProxy, the client can send a diff of changes rather than the entire object graph. This is made possible because EntityProxys have an identity, so the server can fetch the identity from the datastore and then apply the diff/patch sent from the client, and only then the entity will be passed to your service methods.
With ValueProxy you basically have an equivalent of GWT-RPC: the object is reconstructed from scratch on the server, and not associated with your datastore (in the case of JPA for instance, it's not attached to the session). Depending on your datastore API, this can make things more complex to handle in your service methods.
Other than that, you'll also lose the EntityProxyChange events.
I'm building an application with a domain model using CQRS and domain events concepts (but no event sourcing, just plain old SQL). There was no problem with events of SomethingChanged kind. Then I got stuck in implementing SomethingCreated events.
When I create some entity which is mapped to a table with identity primary key then I don't know the Id until the entity is persisted. Entity is persistence ignorant so when publishing an event from inside the entity, Id is just not known - it's magically set after calling context.SaveChanges() only. So how/where/when can I put the Id in the event data?
I was thinking of:
Including the reference to the entity in the event. That would work inside the domain but not necesarily in a distributed environment with multiple autonomous system communicating by events/messages.
Overriding SaveChanges() to somehow update events enqueued for publishing. But events are meant to be immutable, so this seems very dirty.
Getting rid of identity fields and using GUIDs generated in the entity constructor. This might be the easiest but could hit performance and make other things harder, like debugging or querying (where id = 'B85E62C3-DC56-40C0-852A-49F759AC68FB', no MIN, MAX etc.). That's what I see in many sample applications.
Hybrid approach - leave alone the identity and use it mainly for foreign keys and faster joins but use GUID as the unique identifier by which i pull the entities from the repository in the application.
Personally I like GUIDs for unique identifiers, especially in multi-user, distributed environments where numeric ids cause problems. As such, I never use database generated identity columns/properties and this problem goes away.
Short of that, since you are following CQRS, you undoubtedly have a CreateSomethingCommand and corresponding CreateSomethingCommandHandler that actually carries out the steps required to create the new instance and persist the new object using the repository (via context.SaveChanges). I will raise the SomethingCreated event here rather than in the domain object itself.
For one, this solves your problem because the command handler can wait for the database operation to complete, pull out the identity value, update the object then pass the identity in the event. But, more importantly, it also addresses the tricky question of exactly when is the object 'created'?
Raising a domain event in the constructor is bad practice as constructors should be lean and simply perform initialization. Plus, in your model, the object isn't really created until it has an ID assigned. This means there are additional initialization steps required after the constructor has executed. If you have more than one step, do you enforce the order of execution (another anti-pattern) or put a check in each to recognize when they are all done (ooh, smelly)? Hopefully you can see how this can quickly spiral out of hand.
So, my recommendation is to raise the event from the command handler. (NOTE: Even if you switch to GUID identifiers, I'd follow this approach because you should never raise events from constructors.)
I have a SpringServlet (from Jersey) that is exposing my JPA-annotated POJOs in a very basic manner right now. For example, rather than returning an actual represetantion of the object, I've just returned a field such as Name to play around.
Of course I want to return the actual representation of the object as a resource... the part where I am stuck is that if I have an object of type Foo accessible via /foo/{id}/ but it also has a relation to object type Bar as part of Foo -- I don't want to serialize Bar in the response. I want to return a URI to a Bar resource.
Am I on my own from here -- no frameworks handle that part? Especially with regard to the path. It feels like I'm going to have to create BarResource annotated with #Path but then also, during serialization, set the URI for the Bar POJO reference read from a constant. I'm not able to take a type and lookup a resource (and subsequently the #Path annotation) but that would be handy, no?
You are destined to remain confused until you clear up the distinction between resources, representations and objects.
A resource is a concept, or some "thing" that is useful to the client application. It is very nebulous. It is identified by a URI and is operated on using methods. It needs to be nebulous/flexible to make up for the very limited set of methods.
A representation is a set of bytes that can be transferred across the wire that represents the resource as some instant in time.
An object is an implementation detail that may or may not have a direct correlation with a resource. The information contained within a resource may be implemented by a single object or an entire object graph. A resource's contents could be stored in a file, the result of a SQL query, a XSLT transformation, pretty much anything.
You may or many not use object serialization to create representations of resources. References between objects may relate to content within a single resource or links between resources. However, be very careful serializing domain objects into representations. That is sure to introduce a level of coupling between your client and server that you will live to regret.
I have a class called Test which has four public properties and one of them is static. the problem is after deserialization the static property contains null value. i have debugged the code and found that at server side it contains the value which is a collection , but at client side it becomes null after deserialization. i know static members doesn't serialize and deserialize so obviously it should contain the value.
Static variables are global and stateful - thus they exist solely in the context of the application, or in other words, memory.
You could pass the value of the static property in another non-static property, but you can't send your application's memory down to the client.
If the static value is initialised when the type is loaded (via a field initialiser or via the type initialiser/static constructor) then it should contain the value.
If however, the server side static value is initialised as a side effect of some method call, then you would have to reproduce this method call on the client as well.
I'm not sure I understand...as you say in your question:
i know static members doesn't serialize and deserialize...
Given that, why would you expect the value from the server to propagate to the client? You will need to find an alternative means of transferring this property (make an instance property, send your own message, etc.)
Remember that static member values exist within a particular .NET application domain, and application domains exist within a particular operating system process.
Given that the server and client are different operating system processes and possibly even different machines, as Adam mentioned, there is no way for the value you had on the server to automatically transfer to the client without you writing some code.
I think maybe there is a misconception - Serialization is not packaging up the instance and its static members on the server, and sending it down to the client. It is extracting the values of the members it regards as serializable (e.g. members annotated with [DataMember], or instance members, but not static members), and sending down only those values to the client.
Therefore the value on the client will be the same as the value on the server was before you set it to the value you're now expecting to see on the client.
However: I notice you also mention you see that a collection of yours has a null value.
If you are using DataContractSerializer in a PartialTrust environment, be aware that it may not call the constructor of your class.
Quote:
When instantiating the target object during deserialization, the DataContractSerializer does not call the constructor of the target object.
If that collection was created by your constructor, this may explain why you see null.