OmniBase question

Hello all, I am trying to work with OmniBase.

In a WorkSpace i try:

|z|

OmniBase closeAll.

db := OmniBase new.

db openOn: 'c:\temp\prueba1'.

[ z:= Agenda newPersistent. z owner: 'Pablo' ] evaluateAndCommitIn: db
newTransaction.

tr := db newTransaction.

tr getObjectID: z.

tr commit.



the line tr getObjectId: z open a wallback with  Object is not persistent or
is contained in another persistent ........

Why is this ? . z was not made persistent by OmniBase ?.

I am trying to follow the Employee example of D. Gorisek in
PersonnelFilesShell  and i believe i do the same as David.

Can anyone help me?

TIA

It looks like you have a couple of problems here.  My understanding of
OmniBase is limited, but you can try this:

OmniBase closeAll.
db := OmniBase new.
db openOn: 'c:\temp\prueba1'.
[ z:= Agenda newPersistent. z owner: 'Pablo'.
OmniBase root at: 'test' put: z ] evaluateAndCommitIn: db newTransaction.
tr := db newTransaction.
tr root at: test."inspect me"
tr commit.

I changed two things: first, I added a reference to the Agenda object to the
root dictionary of the OmniBase database.  This way you can find it again
later.  In a real application, you would probably add it to an
ODBBTreeDictionary or some other ODB collection reachable from the root
dictionary.

Second,  I accessed the item in the new transaction through the root
dictionary via its key, instead of using getObjectId.  I think that
ODBTransaction>>objectAt: and ODBTransaction>>getObjectID: are used to
'hand-off' a reference from one transaction to another, not for retrieving
the items later after a transaction is over.  But don't quote me on that.

Finally, understand that once you've made z persistent, the only way you can
meaningfully work with 'persistent z' anymore is inside of a transaction.
In the above example, if you add the line:

(tr root at: 'test') = z.

just before your 'tr commit', it will test as false.

Let's say you have an Employee object, which includes the Employee's
Division.  You want to be able to display a presenter for the Employee which
has a combobox with all of the divisions listed, so you can choose the
Division of the Employee.  The Divisions and the Employee are persistent in
OmniBase.

You can't load the Divisions from OmniBase into an OrderedCollection when
you start your program, and use them as the Division choices later when you
show the Employee presenter.  Instead, you'll need to load them in the same
transaction as the Employee itself.  Otherwise, you'll end up with a
Division for the Employee which 'looks' the same as one of the ones in the
database, but isn't.  Your ComboBox will complain next time you try to show
the Employee!

You would also want to to do this:

Employee>>division

    ^division yourself

That makes sure that you're looking at the object itself and not its proxy.

Hope that helps,

Jerry Bell
[hidden email]


"pablo digonzelli" <[hidden email]> wrote in message
news:983771$481e$[hidden email]... or

Thanks Jerry
I'll working on it and then I comment the results.
Pablo
"Jerry Bell" <[hidden email]> wrote in message
news:985jcr$e60j$[hidden email]... the can
> meaningfully work with 'persistent z' anymore is inside of a transaction.
> In the above example, if you add the line:
>
> (tr root at: 'test') = z.
>
> just before your 'tr commit', it will test as false.
>
> Let's say you have an Employee object, which includes the Employee's
> Division.  You want to be able to display a presenter for the Employee
which
> has a combobox with all of the divisions listed, so you can choose the
> Division of the Employee.  The Divisions and the Employee are persistent
in
> OmniBase.
>
> You can't load the Divisions from OmniBase into an OrderedCollection when
> you start your program, and use them as the Division choices later when yo
u
> show the Employee presenter.  Instead, you'll need to load them in the
same
> transaction as the Employee itself.  Otherwise, you'll end up with a
> Division for the Employee which 'looks' the same as one of the ones in the
> database, but isn't.  Your ComboBox will complain next time you try to
show
> the Employee!
>
> You would also want to to do this:
>
> Employee>>division
>
>     ^division yourself
>
> That makes sure that you're looking at the object itself and not its
proxy. persistent

Jerry, thanks for clarifying these things for me. Regarding the use of
object IDs you are right. They shouldn't be used other than for fast
fetching of objects when multiple transactions are involved. Otherwise
objects should have some other primary key value to identify them (if
possible) because then you can exchange data with external systems and
retain data identity. Object ids are very implementation specific.

Best regards,

David

Jerry Bell <[hidden email]> wrote in message
news:985jcr$e60j$[hidden email]... the can
> meaningfully work with 'persistent z' anymore is inside of a transaction.
> In the above example, if you add the line:
>
> (tr root at: 'test') = z.
>
> just before your 'tr commit', it will test as false.
>
> Let's say you have an Employee object, which includes the Employee's
> Division.  You want to be able to display a presenter for the Employee
which
> has a combobox with all of the divisions listed, so you can choose the
> Division of the Employee.  The Divisions and the Employee are persistent
in
> OmniBase.
>
> You can't load the Divisions from OmniBase into an OrderedCollection when
> you start your program, and use them as the Division choices later when
you
> show the Employee presenter.  Instead, you'll need to load them in the
same
> transaction as the Employee itself.  Otherwise, you'll end up with a
> Division for the Employee which 'looks' the same as one of the ones in the
> database, but isn't.  Your ComboBox will complain next time you try to
show
> the Employee!
>
> You would also want to to do this:
>
> Employee>>division
>
>     ^division yourself
>
> That makes sure that you're looking at the object itself and not its
proxy. persistent

Pablo,

Please find my comments below...

pablo digonzelli <[hidden email]> wrote in message
news:983771$481e$[hidden email]...
Here, the prefered way of opening a database would be:

db := OmniBase openOn: 'c:\temp\prueba1'.

or
> is contained in another persistent ........
>
> Why is this ? . z was not made persistent by OmniBase ?.
>

Here the object z was made persistent, but this was done in another
transaction. Transaction is like a view into the world of persistent
objects. In your case for second transaction the object z is just another
transient object simply because it was made persistent in the first
transaction inside of which the block was evaluated. And since one of the
transaction properties is isolation, the other transaction knows nothing
about the object z.
Looking at your example I also don't see what you were trying to achieve.
Object z is just made persistent but it is not being referenced from any
other persistent object. Since there is no way to get to this object by
navigating from the root object, the object will be removed the next time
when the database is garbage collected. When what you were trying to get
object's OID then this would only work if you call the method #getObjectID:
inside the transaction in which the object has been loaded. For new objects
created in a transaction which hasn't been committed yet the object ID is
not known yet because it is given a commit time. So to be sure that you can
get the object ID you should commit the transaction first.

Best regards,

David

>And since one of the
> transaction properties is isolation, the other transaction knows nothing
> about the object z.

Hi David,

What are the other transaction properties?

Thanks,
Steve