create()

[cjohn]

Hi !

I appreciate that I can:
1. Open a txn
2. Create an object
3. Commit the txn - object gets written to database.
4. Do a non-unique read such that the created object is expected to be part of the set. I assume Inq will call the database via a select-stmt.

Then the set will contain the object created in step2.

However, if I now do the:
1. Open a txn
2. Create an object
3. Do a non-unique read such that the created object is expected to be part of the set
4. Commit the txn

How will my set of read objects contain the created object from step2?

Should I use a eligible-clause in my i/o key defn ???

[Tom]

I think there is some confusion surrounding the Inq transaction model and (separately) what an eligibility expression is for.

First the transaction issue. Inq does not behave in the same way as (at least some) database servers do.
After you have called create() the instance you have submitted for creation will not be returned by subsequent read() calls until the transaction has successfully committed, so your first scenario is correct. Step 3 in the second scenario is incorrect - the instance you created will not be in the set. Inq only returns managed instances - that is ones that have been previously committed.

Secondly the eligibility expression. The purpose of an eligibility expression is to maintain cached key values and the instance(s) they map to when the underlying SQL contains an inequality. It is not (as you perhaps have misunderstood) intended to help Inq return instances awaiting formal creation when read() is called.

You might ask why doesn't Inq return to-be-created instances in a read() ? Well, once an instance has been submitted for creation Inq does not allow it to be changed. This is because Inq locks the unique key value(s) the instance represents to protect the transaction's integrity. More on transaction state can be found here: http://www.inqwell.com/primer/txn.html#manip