Actually, we're only using the URI to call SDOUtil.getTypes(), so that
we can pass a list of types to SDOUtil.registerDataGraphTypes(). Maybe
we should just have a registerDataGraphTypes() method that takes a
Factory class as a parameter?
Brent
On 11/1/06, Brent Daniel <[EMAIL PROTECTED]> wrote:
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]
