Internal Website 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 ... each comparison operator. One column presents a comparison of NULL value with a non 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

that comparison with NULL in JPQL follows the SQL rules for NULL comparison rather than the Java rules, as explained in the Comparison Operators page. Boolean Literals Similarly to Java and SQL, JPQL

defined persistable classes can participate in direct comparison using the = and operators ... and functions (e.g. for strings and for numbers ), they can be compared by all six comparison operators ... , the comparison is between the type of the e object (which may represent any path including a root or

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

Java 6/7 Performance Comparison

: * (multiplication), / (division), + (addition) and - (subtraction). Comparison operators ... expressions  ( isEmpty , isNotEmpty , isMember , isNotMember , size ). Comparison expressions

, a comparison of :name to a field whose type is String indicates that the type of :name itself is String ... . This is very useful in comparison against a specific date, when time should be ignored. The get methods

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

whose type is boolean - such as comparison operators: Predicate isLarge = cb. gt (country. get ("area

efficient tracking of persistent field modifications, avoiding the need for snapshot comparison of entities

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

, isMember , isNotMember , size ). Comparison expressions ( equal , notEqual , gt , ge , lt , le , between

to reference a candidate object in other operations, such as method calls and comparison expressions ... . Other types of persistent fields can participate in queries in combination with comparison expressions, as in ... ). Operators Comparison operators Comparison operators ( ==, !=, , = ) generate boolean expressions

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

must correspond to columns for which comparison operators are supported. The dot (".") notation is used

;      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

the indexed field. Both equality ( == , != ) and comparison ( = ) queries are supported by value indexes

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.

comparisons between primitives and instances of wrapper classes are valid. Equality and ordering comparisons of Date fields and Date parameters are valid. White space (non-printing characters space

the Java language, except for these differences: Equality and ordering comparisons between primitives and instances of wrapper classes are valid. Equality and ordering comparisons of Date fields and Date