We Keep Coding

Possible to make a query-able counter using Postgres sequence and Hibernate mapping?

I'm getting the "No data type for node" error when I run this query:
session.createQuery("select nextval( 'next_num_seq' )")
which I know means that I need to make it a property of a class, but I haven't been able to find a way to add a sequence to a class, only how to make a sequence generate IDs for a class.
Is there a way to include a sequence in a Hibernate mapping that isn't an ID generator?

As such, this question is valid, yet the path to the solution is headed in the wrong direction. Mapping a Sequence into a managed domain entity is not a "good" idea, as these are two separate concepts.
Sequences, such as the one you are trying to query from a PostgreSQL backend, are a central concept for the generation of unique IDs for primary key values of tuples or - from an ORM application perspective - Java objects. Thus, it is not clever to map their current state to a domain entity. Instead, one sets a single, particular value drawn from such a sequence - e.g. next_num_seq - into one particular object to be persisted in a relational database. Therefore, the related class of such an domain object is linked to this sequence by, for instance, dedicated ORM annotations (or via similar approaches).
In the JavaDoc of the Session interface we find the method createNativeQuery(String sql) which is inherited from the EntityManager interface, see also here.
It is described as follows:
Query createNativeQuery(java.lang.String sqlString)
Create an instance of Query for executing a native SQL statement, e.g., for update or delete.
Parameters:
sqlString - a native SQL query string
Returns:
the new query instance
Thus, you could modify your code to execute the native query against your PostgreSQL database as follows:
Query q = session.createNativeQuery("select nextval( 'next_num_seq' )");
This gives you the option to read the next valid sequence value as a long or Number instance for your programming purposes.
Note well: Be careful not to reuse this value multiple times (for several objects), as this might cause consistency trouble in your backend when used, for instance, in the context of separate threads.
Hope this helps.

Entities returned by Projection Queries

I'm designing an application in which I hope to use projection queries to retrieve Entity objects from the App Engine Datastore to save on latency and cost. I have two questions about this:
1) If one calls the Entity.getProperty(String propertyName) method on a returned Entity where propertyName does not correspond to one of the properties selected for by the Projection, will the return value be null or will Java throw an exception? The Entity documentation doesn't indicate what happens if propertyName does not exist. A corollary, do the not-selected-for properties no longer exist in the returned Entity or do they simply have no or null values assigned to them?
2) Is the Key of the truncated Entity that is returned the same as the Key of the original full Entity that's actually in the datastore? From what I understand, the Key is a hash of the kind, name/id property, and ancestor path of an Entity. Name/id also appears to be a property, so if one doesn't select for it, does the Key of the returned Entity differ from that of the actual Entity?
These questions seem like they would be fairly easy to answer with some testing once I'm up and running, but I'm new to App Engine and am still just designing my project, so I won't be in a position to do so for a while. Was hoping someone out there already knows the answer.

If a property does not exist in an entity, .getPropery() returns null. No exception is thrown.
If a property is not named in a projection query, the retrieved entity does not have this property even if the full entity does.
The key of an entity returned in a projection query is the same as in any other query. The key is created when an entity is first inserted in the datastore, and it does not change after that.
A little explanation. When you insert a new entity in the datastore, the datastore creates an entity and, separately, creates an entry for each indexed property, or a combination of properties (custom index), in a respective index. Projection query is just another combination of indexed properties. It retrieves all the data it needs directly from its own index without retrieving the entity itself.

Sharing constants between java and database

Assume that you have a STORE table having a varchar column STATUS that accepts values (OPEN,CLOSED)
On java side, and especially in your sqls I find myself writing queries like this
select * from store where status='OPEN'
Now this is not a written contract and is open to lots of bugs.
I want to manage cases where on db side a new status added or an existing one renamed and handle it on java side. For example if on STORE table if all statuses with OPEN are changed to OP, my sql code will fail.
PS:This question is in fact programming language and database server agnostic, but I tag it with java since I deal with it more.

Your need is a bit strange. Usually stuff don't just "happen" in database, and you don't have to cope with it. Rather, you decide to change things in your app(s) and both change your code and migrate your data.
This being said, if you want to ensure your data are consistent with a well-known set of values, you can create library tables. In your case:
create table STORE (status varchar(32)) -- your table
create table LIB_STORE_STATUS (status varchar(32) unique) -- a lib table for statuses
alter table STORE add constraint FK_STORE_STATUS foreign key (status) references LIB_STORE_STATUS(status) -- constraints the values in your STORE table
Then:
insert into STORE values ('A') -- fails
insert into LIB_STORE_STATUS values ('A')
insert into STORE values ('A') -- passes
With this, you just have to ensure your lib table is always in sync with your code (i.e. your enum names when using JPA's #Enumerated(EnumType.STRING) mapping strategy).

Use enums, you can map directrly to the enum instance name (not necessary to convert to the int ordinal)
But in this case I would have a boolean/bit column called open, and its possible values would be true or false.
(boolean is bit 0/1 in most DB's)

db4o to preserve identity of objects

Is there a way to preserve an object identity in db4o.
Suppose I store a BigDecimal in embedded db4o.
When I read it twice I get two distinct objects with the same value (which is quite obvious).
Is there any setting to force db4o to cache query results so that two queries would return reference to the same instance, or do I have to do it myself ?

From my experience, running the same query twice on the same ObjectContainer should return the same (identical) objects each time.
You should not close and reopen the ObjectContainer between the queries, if you need the objects' identity.

Db4o does use IDs and UUIDs internally and you can access those if needed. Also worth reading is this.

you can make an id for each object of yours by using it's UUIDs, I mean add an attribute ID for the object and give it UUIDs value and store it, to update an object you can retrieve it by that Id and update it

Wizard-generated JPA DAO method doesn't return an iterable List

I must be really stupid, but I'm at my wits' end with a JPA issue, using MyEclipse 7.5.
I am accessing a DB2 database (on an AS400) via JPA. I have reverse-engineered a simple table to provide a DAO with some precision "find" methods. So far so good.
If I run a SELECT statement over the table thus, I get 4 rows:
SELECT * FROM MyTable WHERE MyValue = '1234'
However, if I try to access these same 4 records via JPA, I get a list that's the right size (4), but which contains 4 objects which are all the same, all copies of the first object found:
List <MyTableObject> objects = dao.findByMyValue("1234");
It's almost as if the internal Query object that the DAO class creates can't iterate through the rows of data. I've tweaked the reveng.xml file myriad ways, and I've tinkered with the generated DAO, but I'm getting nowhere. Am I missing something really obvious here? I just want to get a list of objects in the same way that the conventional SELECT statement returns a resultset!
(This is MyEclipse 7.5, using Hibernate 3.2 and its associated JPA library).
UPDATE: here's the generated code that findByMyValue() passes over to (loggin / try-catch removed for clarity):
#SuppressWarnings("unchecked")
public List<PolicyStatFile> findByProperty(String propertyName, final Object value)
{
final String queryString = "select model from MyTableObject model where model." + propertyName + "= :propertyValue";
Query query = getEntityManager().createQuery(queryString);
query.setParameter("propertyValue", value);
return query.getResultList();
}
FINAL UPDATE
It was all about the model: see comments to this post. Essentially, the model generated from the reverse engineering file was invalid because I didn't have a truly unique key. Once I resolved this (spurred by comments here), all was well.

Method you've posted looks correct (although it seems rather pointless to generate this for all properties). Couple things to check:
Is MyValue property you've mentioned mapped directly on your entity (e.g. to the column on the same table; no associations are involved)?
Can you enable Hibernate SQL debug (set 'hibernate.show_sql' property to true in your configuration) and check what the generated query looks like?
Are 4 objects returned actually the same (e.g. are '==' to each other) or are they copies of each other (e.g. have the same property values)?
Can you post your mapping for the entity in question and generated SQL from #2 above?

I suspect you haven't overridden hashCode() and equals() in your JPA entity (e.g. MyTableObject). So Hibernate can't distinguish the returning rows. That a look here.