OK.. if we aren't incurring extra processing with each call to
registerStaticTypes() it shouldn't be an issue to do it every time. I
would like to have a utility to get the URI from the factory, though,
so that we can keep our configuration as simple as possible. I'll open
up a JIRA for this.
Thanks,
Brent
On 11/1/06, Frank Budinsky <[EMAIL PROTECTED]> wrote:
Brent,
Why can't DAS check if the types are already registered, and then only
register them if they're not? Actually SDOUtil.registerStaticTypes()
should really be a NO-OP if the types are already registered. If it's not,
we should probably fix that. We can easily add another SDOUtil method to
allow you to get the URI from the Factory class, but putting both the URI
and the Factory class into the config file doesn't sound bad to me.
Frank
"Brent Daniel" <[EMAIL PROTECTED]> wrote on 10/31/2006 08:45:13 PM:
> The down side of this is that the DAS will re-register the types on
> every call to Command.execute(), whereas if this is in the user's
> hands it can be done once per application and then referenced by URI.
> At the moment, I believe that this would also cause us to reintroduce
> a direct dependency on EMF into the DAS, as we would have to do some
> EMF magic to get the Types from the specified factory. We can push
> this down to SDO, but it's not there right now. I think this was why
> we switched to a URI to begin with. You could also have the user
> specify both the factory class and the URI to get around this, but is
> that really simpler than calling SDOUtil.registerStaticTypes()?
>
> I don't have a strong opinion either way. I lean towards the URI
> approach because specifying the name of a factory class file in the
> Config has always seemed ugly to me.
>
> Brent
>
> On 10/31/06, Luciano Resende <[EMAIL PROTECTED]> wrote:
> > I think I run into same issue while playing with BigBank... where I
had to
> > register the types with SDO first..
> >
> > Yes, this sounds like a good enhancement... to have DAS taking care of
the
> > registration part, as long as it's registered in the DAS config...and
would
> > make the customer experience much simpler.
> >
> > +1
> >
> > - Luciano
> >
> > On 10/31/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
> > >
> > > In writing up some documentation around the use of the RDB DAS with
> > > Static Types I noticed something a bit clunky. Here is a current
> > > exampleout of the RDB DAS test suite:
> > >
> > > public void testUserProvidedModel() throws SQLException {
> > >
> > > *SDOUtil.registerStaticTypes(CustomerFactory.class);*
> > >
> > > DAS das =
> > > DAS.FACTORY.createDAS(*getConfig("staticCustomerOrder.xml")*,
> > > getConnection());
> > > Command select = das.getCommand("Customer and Orders");
> > > select.setParameter(1, Integer.valueOf(1));
> > >
> > > DataObject root = select.executeQuery();
> > >
> > > // Modify a customer
> > > Customer customer = (Customer)
root.getDataObject("Customer[1]");
> > > customer.setLastName("Pavick");
> > >
> > > // Modify an order
> > > AnOrder order = (AnOrder) customer.getOrders().get(0);
> > > order.setProduct("Kitchen Sink 001");
> > >
> > > // Flush changes
> > > das.applyChanges((DataObject) root);
> > >
> > > }
> > >
> > > What seems clunky is that the the user must specify the Types to the
DAS
> > > in the config file ("staticCustomerOrder.xml") and also register the
> > > Types with the SDO runtime via:
> > > *"SDOUtil.registerStaticTypes(CustomerFactory.class)"* It might
make
> > > sense for the DAS to register the Types based on the confg info as a
> > > convienience for the user.
> > >
> > > Any thoughts?
> > >
> > > --
> > > Kevin
> > > *
> > > *
> > >
> > >
> > >
---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
