ObjectDB Database Search

, it is supposed that the count of every field should be the same performance . I have no time to test

Hello, we have a performance problem when we use a large transaction. Let's do exactly the same in several transactions the ObjectDB works much faster. In our use case, we create many new entities and between the creations we call a select query. The execution of the query becomes slower at each

we have a customer system with 64 GByte RAM, 16 CPUs on 8 sockets, the fastest possible ssd. we wonder if the cache and other settings can be optimized to get the most performance these are the current settings, please advice what we could optimize hgzpincher Hans-Georg Zwicker

other useful hints for object db?  Performance is better, but still not the same 1000 ms in

Greetings ObjectDB team, The below questions assume a very large database (~1,000,000,000 objects): Q1: If my whole database is read only, is there a way to exploit this and optimize query performance ? Q2: Do LIKE operations have significant degradation on queries

we are fighting more or less since version 2.9 with the performance of our systems. We are completely unclear if indexes or statistics are really used.  sometimes a query like this takes takes around 500 ms, sometimes it takes 20 seconds  select distinct o from ObjectNode o join o

Hi, can someone share expirience with performance limits of ObjectDB especialy when quering tables with large records sets. Our issue is with tables with 100.000+ records. Everything was OK when we had few thousand records. We have a simple SELECT statement which selects from a table with 100.000

Hello, we have a question about a performance issue in a query. We executed a query on the following entity and there is only one entity in the database and we expects that the query is executed within 1 ms. SELECT v.sheetUID FROM TCVector But how you can see in the attached snapshot 'stacktrace

Performance issues on aggregate query

Low performance when getting grove roots

Performance of "InsertTest"

Help: After upgrading from 2.2.8_02 to 2.2.8_04, can't perform LIKE query

slow performance for a complex query

possible index required for improving query performance

we face performance issues on queries and therefore compared the times of 2 (same) databases, 2.9.0_05, one after adding statistics and one after additional doctor, here are the results: Query : select distinct o from ObjectNode o where (o.classIdentifier = '(RG)' and o.properties.name

Performance issue with query

log entry and massive performance issues

Monitoring and Performance counters

. The EntityManager API is used to perform operations that affect the state of the persistence context, or ... is pessimistic and the entity has a version attribute, the persistence provider must perform ... must perform optimistic version checks when obtaining the database lock. If these checks fail

of one class in different 'tables'. Please clarify: Is it only for improving performance , or do you also expect a change in functionality? How exactly performance should be improved if the  ... 'tables'. - Yes Is it only for improving performance , or do you also expect a change in functionality

provider must perform the automatic validation of entities. If no Bean Validation provider is present in ... 2.0 CALLBACK The persistence provider must perform the lifecycle event validation. It is an error ... NONE The persistence provider must not perform lifecycle event validation. Since: JPA 2.0 Public Static Enum Methods

, the persistence provider must also perform optimistic version checks when obtaining the database lock ... - if the entity does not exist in the database when pessimistic locking is performed

a CriteriaDelete query object to perform a bulk delete operation. Parameters: targetEntity - target ... createCriteriaUpdate (Class  targetEntity) Create a CriteriaUpdate query object to perform a bulk update

, the persistence provider must also perform optimistic version checks when obtaining the database lock ... is performed OptimisticLockException - if the optimistic version check fails PessimisticLockException

contains a version attribute, the persistence provider must also perform optimistic version checks ... is performed OptimisticLockException - if the optimistic version check fails PessimisticLockException

JPA Interface CriteriaDelete Type Parameters: - the entity type that is the target of the DELETE Super Interfaces: CommonAbstractCriteria The CriteriaDelete interface defines functionality for performing bulk delete operations using the Criteria API Criteria API bulk delete operations map directly

required to perform any specific validation, so the semantics of this operation are entirely provider

JPA Method in jakarta.persistence.SchemaManager void validate () Validate that the database objects mapped by entities belonging to the persistence unit have the expected definitions. The persistence provider is not required to perform any specific validation, so the semantics of this operation

is pessimistic and the entity has a version attribute, the persistence provider must perform optimistic

has a version attribute, the persistence provider must perform optimistic version checks

} is set. Since: JPA 3.2 SCHEMAGEN_DATABASE_ACTION The action to be performed against the database

JPA Static Field in jakarta.persistence.PersistenceConfiguration SCHEMAGEN_DATABASE_ACTION The action to be performed against the database. Standard actions are: none , create , drop , drop-and-create , validate . Since: JPA 3.2

JPA Method in jakarta.persistence.criteria.Expression Expression as (   Class  type ) Perform a typecast upon the expression, returning a new expression object. Unlike cast , this method does not cause type conversion: the runtime type is not changed. Warning: may result in

JPA Enum Constant in jakarta.persistence.ValidationMode NONE The persistence provider must not perform lifecycle event validation. Since: JPA 2.0

JPA Enum Constant in jakarta.persistence.ValidationMode CALLBACK The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment. Since: JPA 2.0

JPA Enum Constant in jakarta.persistence.ValidationMode AUTO If a Bean Validation provider is present in the environment, the persistence provider must perform the automatic validation of entities. If no Bean Validation provider is present in the environment, no lifecycle event validation takes place. This is the default behavior. Since: JPA 2.0

file buffer (the result of the transform), or null if no transform is performed Throws

JPA Interface Expression Type Parameters: - the type of the expression Super Interfaces: Selection , TupleElement Type for query expressions. Since: JPA 2.0 The JPA Query Expressions (JPQL / Criteria) article explains how to use Expression . Public Methods Expression as (Class  type) Perform

JPA Interface ParameterExpression Type Parameters: - the type of the parameter expression Super Interfaces: Expression , Parameter , Selection , TupleElement Type of criteria query parameter expressions. Since: JPA 2.0 Public Methods Expression as (Class  type) Perform a typecast

, the persistence provider must perform optimistic version checks when obtaining the database lock

otherwise. Since: JPA 2.0 Public Methods Expression as (Class  type) Perform a typecast upon the expression

is performed via the EntityTransaction interface. Since: JPA 3.2 Enum Constants JTA Transaction management

and the entity has a version attribute, the persistence provider must perform optimistic version checks

of the transform), or null if no transform is performed Throws: TransformerException - if the input does not represent a well-formed class file Since: JPA 1.0

JPA Method in jakarta.persistence.criteria.CriteriaBuilder CriteriaUpdate createCriteriaUpdate (   Class  targetEntity ) Create a CriteriaUpdate query object to perform a bulk update operation. Parameters: targetEntity - target type for update operation Return: the query object Since: JPA 2.1

. Since: JPA 2.0 Public Methods Expression as (Class  type) Perform a typecast

JPA Method in jakarta.persistence.criteria.CriteriaBuilder CriteriaDelete createCriteriaDelete (   Class  targetEntity ) Create a CriteriaDelete query object to perform a bulk delete operation. Parameters: targetEntity - target type for delete operation Return: the query object Since: JPA 2.1

JPA Interface CriteriaUpdate Type Parameters: - the entity type that is the target of the update Super Interfaces: CommonAbstractCriteria The CriteriaUpdate interface defines functionality for performing bulk update operations using the Criteria API. Criteria API bulk update operations map

Hello, currently we take some effort to improve the overall performance of our product. ObjectDB is the main data provider within our solution. In the past we often discovered performance problems ... the MyValue object before returning them but we could not see some performance improvement or

. For a number of different List fields, a query performed immediately after creating and persisting many Element objects gives expected results, but the same query performed later form a served JSF page ... of createData() I perform an echoed query on all elements and interrogate the ownedElements list, which gives