Chapter 15. Data Management - 1 views
-
abstractEntity.uid();
-
kuni katsuya on 23 Apr 13sets the uid before persist
-
-
UUID.randomUUID().toString();
-
AbstractEntity
- ...70 more annotations...
-
@MappedSuperclass
-
Important things on ID/UID
-
entity lives in three layers:
-
Flex client
-
JPA persistence context
-
database
-
When updating existing entities coming from the database
-
id is defined and is maintained in the three layers during the different serialization/persistence operations
-
when a new entity is being created in any of the two upper layers (Flex/JPA)
-
new entity has no id until it has been persisted to the database
-
most common solution is to
-
have a second persisted id, the uid
-
which is created by the client and persisted along with the entity
-
recommended approach to avoid any kind of subtle problems is to have a real uid property which will be persisted in the database but is not a primary key for efficiency concerns
-
You can now ask Tide to
-
limit the object graph before sending it
-
Flex with the following API :
-
EntityGraphUnintializer
-
uninitializeEntityGraph
-
Person object will be uninitialized
-
uperson contains
-
only the minimum of data
-
to correctly merge your changes in the server persistence context
-
Tide uses the
-
client data tracking
-
to determine which parts of the graph need to be sent
-
Calling the EntityGraphUninitializer manually is a bit tedious and ugly, so there is a cleaner possibility when you are using generated typesafe service proxies
-
annotate your service method arguments with @org.granite.tide.data.Lazy :
-
@Lazy
-
take care that you have added the [Lazy] annotation to your Flex metadata compilation configuration
-
in the Flex application, register the UninitializeArgumentPreprocessor component in Tide as follows :
-
[UninitializeArgumentPreprocessor]
-
all calls to PersonService.save() will
-
automatically use a properly uninitialized version
-
of the person argument.
-
15.4. Dirty Checking and Conflict Handling
-
simplify the handling of data between Flex and Java EE
-
Chapter 15. Data Management
-
Tide maintains a client-side cache of entity instances and ensures that every instance is unique in the Flex client context
-
uid().hashCode();
-
Tide currently only supports Integer or Long version fields, not timestamps and that the field must be nullable
-
in a multi-tier environment (@Version annotation)
-
highly recommended to use
-
JPA optimistic locking
-
highly recommended to add a
-
persistent uid field
-
AbstractEntity
-
in general this identifier will be
-
initialized from Flex
-
@Column(name="ENTITY_UID", unique=true, nullable=false, updatable=false, length=36) private String uid;
-
@Version private Integer version;
-
uid().equals(((AbstractEntity)o).uid())
-
consistent identifier through all application layers
-
@PrePersist
-
15.3. Reverse Lazy Loading
-
15.4. Dirty Checking and Conflict Handling
-
15.4. Dirty Checking and Conflict Handling
-
15.4. Dirty Checking and Conflict Handling
-
Dirty Checking and Conflict Handling
-
entity instance can be in two states :
-
Stable
-
Dirty
-
property meta_dirty is
-
bindable
-
could be used
-
to enable/disable a Save button
-
correct way of knowing if any object has been changed in the context, is to use the property meta_dirty of the Tide context
-
tideContext.meta_dirty
-
reliable when using optimistic locking
-
check that its @Version field has been incremented