JPA Tutorial 4 - Inheritance and Polymorphic Queries
Group items matching
in title, tags, annotations or url
15More
schuchert - JPA Tutorial 4 - Inheritance and Polymorphic Queries - 0 views
-
-
Books and Dvd's, both of which inherit from Resource
-
When we search for a Resource we might get back Books, Dvd's, or both
- ...12 more annotations...
-
queries polymorphic
-
Introduce the Resource class
-
new type, Dvd
-
What happens when you perform a query on a type that has subclasses?
-
It turns out support for inheritance in queries (as well as JPA) is built in
-
do not actually need to do anything other than have one entity inherit from another entity to get everything to work
-
book entity inherit from the Resource entity
-
Introduce a new entity type called Resource
-
Change the BookDao to be a ResourceDao
-
Update the methods returning Book and have them instead return Resource
-
Update all references to Book and replace them with Resource
-
Change the bookId to resourceId
16More
MySQL Error Number 1005 Can't create table '.mydb#sql-328_45.frm' (errno: 150) | VerySi... - 0 views
-
MySQL Error Number 1005 Can’t create table
-
(errno: 150)
-
SHOW ENGINE INNODB STATUS
- ...12 more annotations...
-
Known Causes:
-
First Steps:
-
dreaded errno 150:
-
The two key fields type and/or size is not an exact match
-
One of the key field that you are trying to reference does not have an index and/or is not a primary key
-
One or both of your tables is a MyISAM table
-
You have specified a cascade ON DELETE SET NULL, but the relevant key field is set to NOT NULL
-
Make sure that the Charset and Collate options are the same both at the table level as well as individual field level for the key columns
-
You have a default value (ie default=0) on your foreign key column
-
You have a syntax error in your ALTER statement or you have mistyped one of the field names in the relationship
-
The name of your foreign key exceeds the
-
max length of 64 chars
-
28More
MySQL :: MySQL 5.7 Reference Manual :: 5.4.4.2 Configurable InnoDB Auto-Increment Locking - 0 views
-
Configurable
-
-
table-level locks held until the end of a statement make INSERT statements using auto-increment safe for use with
-
statement-based replication
- ...24 more annotations...
-
However, those locks limit concurrency and scalability when multiple transactions are executing insert statements at the same time
-
For INSERT statements where the number of rows to be inserted is known at the beginning of processing the statement, InnoDB quickly allocates the required number of auto-increment values without taking any lock, but only if there is no concurrent session already holding the table-level AUTO-INC lock (because that other statement will be allocating auto-increment values one-by-one as it proceeds)
-
obtains auto-increment values under the control of a mutex (a light-weight lock) that is not held until the statement completes, but only for the duration of the allocation process
-
innodb_autoinc_lock_mode = 0 (“traditional” lock mode)
-
special table-level AUTO-INC lock is obtained and held to the end of the statement
-
lock mode is provided for:
-
Backward compatibility.
-
innodb_autoinc_lock_mode = 1 (“consecutive” lock mode)
-
important impact of this lock mode is significantly better scalability
-
This mode is safe for use with
-
statement-based replication
-
innodb_autoinc_lock_mode = 2 (“interleaved” lock mode)
-
This is the fastest and most scalable lock mode
-
but it is
-
not safe
-
when using
-
statement-based replication
-
recovery scenarios when SQL statements are replayed from the binary log
-
Using auto-increment with replication
-
set innodb_autoinc_lock_mode to 0 or 1 and use the same value on the master and its slaves
-
Auto-increment values are not ensured to be the same on the slaves as on the master if you use innodb_autoinc_lock_mode = 2 (“interleaved”) or configurations where the master and slaves do not use the same lock mode
-
If you are using
-
row-based replication
-
all of the auto-increment lock modes are safe
74More
Chapter 15. Data Management - 1 views
-
abstractEntity.uid();
-
-
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