You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Kevin Williams <ke...@qwest.net> on 2006/07/07 04:48:53 UTC
DAS named parameters
I am in the middle of removing the "named parameter" feature of DAS
command and notice that we currently allow a special convenience name to
allow a client to retrieve a database generated ID from a low-level
insert command like this:
DAS das = DAS.FACTORY.createDAS(getConnection());
Command insert = das.createCommand("insert into COMPANY (NAME)
values (?)");
insert.setParameter(1, "AAA Rental");
insert.execute();
Integer key = (Integer) insert.getParameter("generated_key");
I expect that clients will typically not execute a low level insert like
this. Instead, I expect them to pass a modified graph to the DAS and
the DAS will generate and execute a set of insert statements. Any
database-generated IDs will be propagated back to the provided data
graph and the client can access them there.
That said, I think this is a nice low-level feature so I hate to get rid
of it. But, I am removing named parameter access. I suppose I could
provide a special convenience parameter index to serve the same
purpose. Something like:
Integer key = (Integer) insert.getParameter(DAS.GENERATED_KEY);
That would work but seems a bit cheesy ... maybe no cheesier than the
special name. Any other ideas?
Thanks,
--Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS named parameters
Posted by Brent Daniel <br...@gmail.com>.
Kevin,
That's fine, but I would still prefer a specific method for
retrieving a generated key in this case. It seems a lot more intuitive
to me.
Brent
On 7/7/06, Kevin Williams <ke...@qwest.net> wrote:
> Actually, I am proposing that we get rid of getParameter(String) and
> define a special "index" to allow indexed access to the generated id.
> Something like:
>
> public interface Command {
> public static final int GENERATED_KEY = Integer.MAX_VALUE;
>
> and then clients could use it like this:
>
> int key = insert.getParameter(GENERATED_KEY);
>
> What do you think?
>
>
> Brent Daniel wrote:
>
> > Kevin,
> >
> > I think a method such as Command.getGeneratedKey() would be more
> > appropriate. If named parameters are removed, "DAS.GENERATED_KEY"
> > would really be the only possible argument for a getParameter(String)
> > method. Instead of keeping this method around for this one case, we
> > may as well simplify it by changing the name and removing the
> > argument.
> >
> > Otherwise, we can simply remove the method and force clients to use
> > the indexed API. A client would be forced to do this for any other
> > computed columns beside the key anyway.
> >
> > Brent
> >
> >
> > On 7/6/06, Kevin Williams <ke...@qwest.net> wrote:
> >
> >> I am in the middle of removing the "named parameter" feature of DAS
> >> command and notice that we currently allow a special convenience name to
> >> allow a client to retrieve a database generated ID from a low-level
> >> insert command like this:
> >>
> >> DAS das = DAS.FACTORY.createDAS(getConnection());
> >> Command insert = das.createCommand("insert into COMPANY (NAME)
> >> values (?)");
> >> insert.setParameter(1, "AAA Rental");
> >> insert.execute();
> >> Integer key = (Integer) insert.getParameter("generated_key");
> >>
> >> I expect that clients will typically not execute a low level insert like
> >> this. Instead, I expect them to pass a modified graph to the DAS and
> >> the DAS will generate and execute a set of insert statements. Any
> >> database-generated IDs will be propagated back to the provided data
> >> graph and the client can access them there.
> >>
> >> That said, I think this is a nice low-level feature so I hate to get rid
> >> of it. But, I am removing named parameter access. I suppose I could
> >> provide a special convenience parameter index to serve the same
> >> purpose. Something like:
> >>
> >> Integer key = (Integer) insert.getParameter(DAS.GENERATED_KEY);
> >>
> >> That would work but seems a bit cheesy ... maybe no cheesier than the
> >> special name. Any other ideas?
> >>
> >> Thanks,
> >>
> >> --Kevin
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS named parameters
Posted by Kevin Williams <ke...@qwest.net>.
Actually, I am proposing that we get rid of getParameter(String) and
define a special "index" to allow indexed access to the generated id.
Something like:
public interface Command {
public static final int GENERATED_KEY = Integer.MAX_VALUE;
and then clients could use it like this:
int key = insert.getParameter(GENERATED_KEY);
What do you think?
Brent Daniel wrote:
> Kevin,
>
> I think a method such as Command.getGeneratedKey() would be more
> appropriate. If named parameters are removed, "DAS.GENERATED_KEY"
> would really be the only possible argument for a getParameter(String)
> method. Instead of keeping this method around for this one case, we
> may as well simplify it by changing the name and removing the
> argument.
>
> Otherwise, we can simply remove the method and force clients to use
> the indexed API. A client would be forced to do this for any other
> computed columns beside the key anyway.
>
> Brent
>
>
> On 7/6/06, Kevin Williams <ke...@qwest.net> wrote:
>
>> I am in the middle of removing the "named parameter" feature of DAS
>> command and notice that we currently allow a special convenience name to
>> allow a client to retrieve a database generated ID from a low-level
>> insert command like this:
>>
>> DAS das = DAS.FACTORY.createDAS(getConnection());
>> Command insert = das.createCommand("insert into COMPANY (NAME)
>> values (?)");
>> insert.setParameter(1, "AAA Rental");
>> insert.execute();
>> Integer key = (Integer) insert.getParameter("generated_key");
>>
>> I expect that clients will typically not execute a low level insert like
>> this. Instead, I expect them to pass a modified graph to the DAS and
>> the DAS will generate and execute a set of insert statements. Any
>> database-generated IDs will be propagated back to the provided data
>> graph and the client can access them there.
>>
>> That said, I think this is a nice low-level feature so I hate to get rid
>> of it. But, I am removing named parameter access. I suppose I could
>> provide a special convenience parameter index to serve the same
>> purpose. Something like:
>>
>> Integer key = (Integer) insert.getParameter(DAS.GENERATED_KEY);
>>
>> That would work but seems a bit cheesy ... maybe no cheesier than the
>> special name. Any other ideas?
>>
>> Thanks,
>>
>> --Kevin
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: DAS named parameters
Posted by Brent Daniel <br...@gmail.com>.
Kevin,
I think a method such as Command.getGeneratedKey() would be more
appropriate. If named parameters are removed, "DAS.GENERATED_KEY"
would really be the only possible argument for a getParameter(String)
method. Instead of keeping this method around for this one case, we
may as well simplify it by changing the name and removing the
argument.
Otherwise, we can simply remove the method and force clients to use
the indexed API. A client would be forced to do this for any other
computed columns beside the key anyway.
Brent
On 7/6/06, Kevin Williams <ke...@qwest.net> wrote:
> I am in the middle of removing the "named parameter" feature of DAS
> command and notice that we currently allow a special convenience name to
> allow a client to retrieve a database generated ID from a low-level
> insert command like this:
>
> DAS das = DAS.FACTORY.createDAS(getConnection());
> Command insert = das.createCommand("insert into COMPANY (NAME)
> values (?)");
> insert.setParameter(1, "AAA Rental");
> insert.execute();
> Integer key = (Integer) insert.getParameter("generated_key");
>
> I expect that clients will typically not execute a low level insert like
> this. Instead, I expect them to pass a modified graph to the DAS and
> the DAS will generate and execute a set of insert statements. Any
> database-generated IDs will be propagated back to the provided data
> graph and the client can access them there.
>
> That said, I think this is a nice low-level feature so I hate to get rid
> of it. But, I am removing named parameter access. I suppose I could
> provide a special convenience parameter index to serve the same
> purpose. Something like:
>
> Integer key = (Integer) insert.getParameter(DAS.GENERATED_KEY);
>
> That would work but seems a bit cheesy ... maybe no cheesier than the
> special name. Any other ideas?
>
> Thanks,
>
> --Kevin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org