ObjectDB Database Search

Most JPQL queries use at least one comparison operator in their WHERE clause. Comparison operators ObjectDB supports two sets of comparison operators, as shown in the following table: Set 1: JPQL ... how each comparison operator handles NULL values. One column shows the result of comparing a NULL value

Hello, Using ODB 2.4.5 and the Criteria API, doing a simple equals comparison with java.sql.Date value doesn't match any results in the database. Our code looks like this: CriteriaBuilder builder ... everywhere also in the Entity property field to ensure pure date comparison and saving without time parts

I am having trouble getting a simple string comparison to work in an SQL "where" clause.  It is my understanding that queries are case sensitive by default and I do not want that, so I am constructing the query as follows... SELECT e FROM Exercise AS e WHERE UPPER(e.name) = ?0 and then I

ObjectDB and DB4O are the only two real object database I known. Why didn't you give a comparison between them in JPA Performance Benchmark (JPAB)?  TIA gzdillon Lai Yang The focus of JPAB is JPA implementations and ObjectDB is the only object database that supports JPA

are equivalent. Comparison with NULL in JPQL follows SQL rules for NULL comparison rather than Java rules, as explained on the Comparison Operators page. Boolean literalsLiterals Similar to Java and SQL, JPQL

persistent classes can participate in direct comparisons by using the = and operators ... by all six comparison operators and used for ordering . Navigation through path expressions A path ... (Country.class)); In the preceding example, the comparison is between the type of the e object

Java 6/7 Performance Comparison

: * (multiplication), / (division), + (addition), and - (subtraction) Comparison operators ... , isNotEmpty , isMember , isNotMember , size ) Comparison expressions ( equal , notEqual , gt , ge , lt , le

Naturally, this is not the place to look for an unbiased answer for this question. However, you should consider the following points when doing your own objective comparison of object databases: ObjectDB is unique in supporting the standard APIs. It is the only object database with built in

comparison operators: Predicate isLarge = cb. gt (country. get ("area"), 1000000); AND / OR

of persistent field modifications, which avoids the need for snapshot comparison of entities (as

is discarded. This is useful for comparisons against a specific date when the time component

navigation expressions using the dot (.) operator. Comparison operators (

, ...) Collection expressions ( isEmpty , isNotEmpty , isMember , isNotMember , size ) Comparison expressions

within it. The properties or fields used in the ordering must correspond to columns for which comparison

But what about: http://www.objectdb.com/java/jpa/query/jpql/ comparison Section "Comparable Data Types" Comparison ... to prefer value comparison as suggested in #2 above: Value comparison is compatible with JPA and therefore more portable. Value comparison could be more efficient (especially if indexes are defined

; Thanks P. pedwards Paul Edwards You are right about comparison of entity objects - it is based on ID comparison . It is unclear why you manage two levels of nested lists. For the simplicity ... are currently used in such comparison , so it might be still more efficient to use multiple JOINs in this case

duplicating this information into an additional persistent field. The comparison failed because of comparing ... is for literals, so it cannot contain variables or parameters. In comparison the operand types must match. Not

factors. For example, if your classes have many indexes - smart comparison might be faster ... can help. ObjectDB does such comparisons internally to determine if a merged object

;      EMF.close();     } as a comparison I ran it with simple

" but it works fine with an relationship comparison : "SELECT a,b FROM A a LEFT OUTER JOIN a.listB b

and an automatic comparison of old schema vs new schema is the only reliable way of making sure database

more than the database id for generation or comparison , it all fails horribly. Have a look at the output from

. The usual comparison methods are used rather than before and after: import java.util.Calendar; import

, do you agree? chris Christoph Ernst I am not sure that this comparison is valid, since the type

Possible issue for JPQL IS EMPTY comparison expression: SELECT e FROM MyEntity e WHERE e.collection-valued IS EMPTY throws javax.persistence.PersistenceException: Invalid operand type  for operator IS EMPTY (error 756) Thanks. Note: It doesn' t work with SIZE(): SELECT e FROM MyEntity e

the result as an argument for direct comparison with the date field? support Support   Yes

. SQLite in comparison responds within few seconds on average with the same number of records. We hope

Hi, I realize this is kind of like an apples vs. oranges  comparison , but I would be interested if you have any performance information vs. something like ehcache with a persistent store. I'm currently evaluating for a simple schema to persist only 1 or 2 types of entities

retrieval and reading operations (see this comparison ). But obviously a HashMap in memory is faster

it still might be slower than other  comparison operators. An index on the string field

Hello , whats the best Filesystem do you recommend for speed for objectdb? As far i know these ; btrfs , extfs4 , extfs3 , zfs , ntfs , fat32 , EXOFS , Lustre   Which one do you recommend ?     kadirbasol Kadir BASOL We have no such comparison data so we cannot recommend

comparison of object states in order to find which objects in the persistence context have been modified

a difference ? If so, in order to perform a truly scientifically clean comparison , I might be able

system overhead is minimal. See for example comparison of RAM drives , including against a regular hard disk

? thanks! Alex quasado Alexander Adam You can use a JPQL query with a simple date comparison : SELECT p

" method use more than the database id for generation or comparison , it all fails horribly. Have a look

an object language to an object database. And I agree with most of the comparisons that we've ... ) for more documentation? AlphaOne Ron Brennan  I agree with most of the comparisons that we've probably all seen ... who published these comparisons . Actually the differences between JPA and JDO technical capabilities are quite

EntityManagerFactory instantiation . Fixed a bug in comparison of collections to values in queries.

saved content, so changes are detected. Enhancement mode is optimized to skip this comparison

Changed log format to include date and time . Changed class loader management. Fixed handling multiple order expressions in inverse (mapped by) fields. Fixed the behavior of CacheStoreMode setting in L2 shared cache. Fixed  TreeSet and TreeMap  element comparison bugs. Fixed an Explorer

elements are loaded lazily and not ready for comparison when the tree is built. Build 2.7.6_02

with no wildcard characters. Fixed support of embedded objects comparison in queries. Fixed an ArrayIndexOutOfBoundsException  in serializing entity objects.