Embeddable Id: Complex primary keys are also unsupported

[luxspes]

Hi!

Found another inconvenience, this time with an @Embeddable @Id (The
problem here is that I need to deal with some legacy tables, not
designed with a single field primary key, and when I try to create a
new object from the UI I get this error:

The following exception occurred while evaluating fieldpath: :
action="$actionClicked", Component:
ariba.ui.meta.layouts.MetaActionList@d3db5a
The following exception occurred while evaluating fieldpath: :
action="$action", Component: ariba.ui.widgets.TextButton@1aa39a3
Meta Context: Context: (18 entries)
class : mx.gob.tabasco.sbmi.entity.EntidadFederativa X
module : mx.gob.tabasco.sbmi.entity.EntidadFederativa
module_trait : ( ModuleClassPage ) ^
layout : SearchPage X
layout : SearchPortlet X
dataSourceType :
ariba.ui.meta.persistence.ObjectContextDataSource
displayGroup : true
operation : list
class_trait : tableZones ^
class : mx.gob.tabasco.sbmi.entity.EntidadFederativa
layout : ButtonArea
layout_trait : StaticActionButtons ^
filterActions : static
actionCategory : Manage X
action : Create X
action_trait : pageAction ^
actionCategory : Manage
action : Create
PropertyActivation...
scopeKey : action !
editing : false
trait : pageAction
Props:
class_trait:tableZones;
action_trait:pageAction;
module_trait:[ModuleClassPage];
pageName:MetaContentPage;
layout_trait:StaticActionButtons;
actionCategory:Manage;
layout:ButtonArea;
action:Create;
pageBindings:{operation:create; clientPanel:null; layout:Inspect;
object:${displayGroup.insert()}};
actionResults:${requestContext.pageWithName(properties.pageName)};
trait:pageAction;
Component Path:
a:GenericContainer(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/
src/aribaweb/ariba/ui/aribaweb/core/AWGenericActionTag.awl:110)
AWGenericActionTag(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/
src/widgets/ariba/ui/widgets/TextButton.awl:138)
TextButton(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/src/
metaui/ariba/ui/meta/layouts/MetaActionList.awl:63)
m:IncludeComponent(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/
src/metaui/ariba/ui/meta/layouts/MetaSearch.awl:17)
m:IncludeComponent(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/
src/metaui/ariba/ui/meta/layouts/MetaDashboardLayout.awl:45)
AWIncludeBlock(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/src/
metaui/ariba/ui/meta/layouts/MetaDashboardLayout.awl:20)
AWIncludeBlock(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/src/
metaui/ariba/ui/meta/layouts/MetaContentPage.awl:2)


At work, I am using an SeamGen (a much simpler UI generator) that is
also unable to deal with complex legacy primary key, what I did in
that case was that I added support of the
"@org.hibernate.annotations.Entity(mutable=false) " annotation, and I
generate a read-only UI for all the @Entities that are marked as
immutable (but it appears that Ariba does not recognize it either)

The immutable annotation is, of course, only a workaround, I really
think Ariba should support entities with complex primary keys, I do
not consider them a good practice, but sadly the world is full of
legacy systems that use complex primary keys.

Regards,

[arib...@gmail.com]

Hi Luxspes,

It is true: we don't currently support compound keys in metaui-jpa. I
don't see any huge inconvenience pulling it off, but it's not there
now.

Let me just be clear to anyone reading this thread though:
* AribaWeb is a *modular* system
* 95% of AribaWeb (e.g. AribaWeb Core, Widgets, and even MetaUI)
have nothing to do with the issues discussed here
- You can use them with any persistence engine you choose
- They have specific binding to, or restrictions around,
Hibernate, JPA, etc
* The comments here relate only to a *add on module* to AW called
MetaUI-JPA, not to the bulk of the framework.

All that said, we'd like to make MetaUI-JPA as complete as possible,
so please keep the bug reports coming.

Thanks!

[luxspes]

Hi!

Ok, sorry for not being specific :-(, I'll try to be more precise in
my future bug reports :-)

¿How about supporting @org.hibernate.annotations.Entity
(mutable=false) as a short term workaround?

Or is there another MetaUI specific annotation to say that an Entity
should be treated as read only?

Regards,

LuxSpes

[Craig Federighi]

> ¿How about supporting @org.hibernate.annotations.Entity
> (mutable=false) as a short term workaround?

Sure.

You can add something like this in your rules.oss:
class= mx.gob.tabasco.sbmi.entity.EntidadFederativa {
editing:false;
action { editing:false }
field { editing:false }
}

(It's actually just a teeny bit of code to add an AnnotationListener
that will do the same, but I'll spare you the details for now...)

BTW, For now you may also want to add this:
class operation {
action=(Delete, Create) { visible:$properties.editing; }
}

Thanks,

- craig

[luxspes]

So... are you sure there are no huge inconveniences for pulling it
off?

How much time do you think it will take to support this? (do you think
it could be supported by the final release of 5.0 ? or perhaps for
5.1?)
I ask because I have tried other UI meta (and non-meta) generators for
hibernate and none of them support this feature, so
I am starting to think it is really hard to implement (specially
because hibernate (jpa?) support for it is a little bit poor)

On Feb 26, 8:24 pm, ariba...@gmail.com wrote:

[luxspes]

I have been taking a look at the create method inside the
ObjectContext class:

public <T> T create (Class<T> tClass)
{
T o = (T)ClassUtil.newInstance(tClass);
Assert.that(o != null, "Unable to create instance of class:
%s", tClass.getName());
persist(o);
return o;
}


This creates a new object of the right type, and immediately tries to
persist it, I think this could be the root cause for the crash
described in the first post of this thread, AFAIK to be able to
"persist" an object using entityManager.persist (called inside persist
in the JPAContext class that inherits from ObjectContext) that object
has to have a primary key already defined (or have a single column
primary key that is autogenerated)

Am I right?

Another problem with this approach is that (in Hibernate at least) is
that entityManager.persist is not warrantied "not to touch the
database" for databases that do not support sequences (like SqlServer)
and therefore, IIRC if any not nullable fields are still null, it will
crash, ¿how do you deal with this problem?

Regards,

[Craig Federighi]

Hi Luxspes,

The issues that you've identified here are likely all real --
Hibernate's handling of primary keys has some real limitations.
(We've managed up to now by using objects with auto-generated (single
field) keys).

Do you have any recommendations? We could have JPAContext keep a List
of newly created objects and defer calling persist until the first
attempted save...

- craig

>>>> a:GenericContainer(/C:/Users/Luxspes/Libraries/
>>>> aribaweb-5.0RC1/
>>>> src/aribaweb/ariba/ui/aribaweb/core/AWGenericActionTag.awl:110)
>>>> AWGenericActionTag(/C:/Users/Luxspes/Libraries/
>>>> aribaweb-5.0RC1/

>>>> src/widgets/ariba/ui/widgets/TextButton.awl:138)
>>>> TextButton(/C:/Users/Luxspes/Libraries/aribaweb-5.0RC1/src/
>>>> metaui/ariba/ui/meta/layouts/MetaActionList.awl:63)

>>>> m:IncludeComponent(/C:/Users/Luxspes/Libraries/
>>>> aribaweb-5.0RC1/
>>>> src/metaui/ariba/ui/meta/layouts/MetaSearch.awl:17)
>>>> m:IncludeComponent(/C:/Users/Luxspes/Libraries/
>>>> aribaweb-5.0RC1/
>>>> src/metaui/ariba/ui/meta/layouts/MetaDashboardLayout.awl:45)
>>>> AWIncludeBlock(/C:/Users/Luxspes/Libraries/
>>>> aribaweb-5.0RC1/src/
>>>> metaui/ariba/ui/meta/layouts/MetaDashboardLayout.awl:20)
>>>> AWIncludeBlock(/C:/Users/Luxspes/Libraries/
>>>> aribaweb-5.0RC1/src/

[luxspes]

Maybe a List of newly created objects could solve the problem, but we
could get in to trouble trying to maintain uniquing consistency after
querying to the database (what if other user created an object that
"matches" the compound id of ours?)

I would like to try with other JPA providers... do I have to do
something other than changing the hibernate jars with
EclipseLink or Cayenne jars? I have been posting questions in their
forums and they seem to be belive that their implementations are
immune to this problems....

BTW if I want to try with a non JPA compliant API (Cayenne Classic for
example), or test the list idea but inheriting from JpaObjectContext
instead of messing with Ariba internal code... what would I have to
do to register with Ariba a new custom ObjectContext?

Regards,

[Craig Federighi]

> Maybe a List of newly created objects could solve the problem, but we
> could get in to trouble trying to maintain uniquing consistency after
> querying to the database (what if other user created an object that
> "matches" the compound id of ours?)

No matter how you cut it, you'll need a key allocation approach that
avoids issuing duplicate keys...

> I would like to try with other JPA providers... do I have to do
> something other than changing the hibernate jars with
> EclipseLink or Cayenne jars

Yes. You'll notice that there's a HibernateContext (subclass of JPA
context) that implements a few abstract methods in JPAContext -- you'd
have to do something equivalent for your other implementations.

> BTW if I want to try with a non JPA compliant API (Cayenne Classic for
> example), or test the list idea but inheriting from JpaObjectContext
> instead of messing with Ariba internal code... what would I have to
> do to register with Ariba a new custom ObjectContext?

There's some discussion of that topic here:
http://groups.google.com/group/aribaweb/browse_thread/thread/13cb120d8a8f43f0/45abb888ec6f42b6?lnk=gst&q=ObjectContext#45abb888ec6f42b6

- craig

[luxspes]

I may have confirmed it, EclipseLink defers validation to transaction
commit, Hibernate on the other hand, validates at
entityManager.persist ( http://luxspes.blogspot.com/2009/03/entitymanagerpersist-what-does-it-mean.html
).

I am going to retry AribaWeb support for compound primary keys using
EclipseLink as the JPA provider and report on my results later.

On Mar 12, 3:49 pm, Craig Federighi <craig.federi...@gmail.com> wrote:
> > Maybe a List of newly created objects could solve the problem, but we
> > could get in to trouble trying to maintain uniquing consistency after
> > querying to the database (what if other user created an object that
> > "matches" the compound id of ours?)
>
> No matter how you cut it, you'll need a key allocation approach that  
> avoids issuing duplicate keys...
>
> > I would like to try with other JPA providers... do I have to do
> > something other than changing the hibernate jars with
> > EclipseLink or Cayenne jars
>
> Yes.  You'll notice that there's a HibernateContext (subclass of JPA  
> context) that implements a few abstract methods in JPAContext -- you'd  
> have to do something equivalent for your other implementations.
>
> > BTW if I want to try with a non JPA compliant API (Cayenne Classic for
> > example), or test the list idea but inheriting from JpaObjectContext
> > instead of messing with Ariba internal code... what  would I have to
> > do to register with Ariba a new custom ObjectContext?
>
> There's some discussion of that topic here:

>        http://groups.google.com/group/aribaweb/browse_thread/thread/13cb120d...

> ...
>
> read more »

[Craig Federighi]

Great! We'd love to include Top(Eclipse)Link support with Metaui-jpa
(right along side the Hibernate support).

- craig