[ http://issues.apache.org/jira/browse/OJB-16?page=comments#action_62474 ]
Vadim Gritsenko commented on OJB-16:
------------------------------------
> on the OJB level the find-by-pk and find-by-fk (or rather,
> find-by-some-fields) differ only in that in the first case
> OJB can determine which fields to use,
True. All primary key values has to be fed into the stored procedure. That's
how patch currently implements it. Hence, no need for additional configuration
(as for other procedure types).
> and in which order
> whereas in the second case, the user has to specify this.
As I do not want to go into providing muliple procedures for each reference of
collection, I decided to go with single retrieve-by-fk procedure, which can
handle any relation.
In order to do this, this procedure must take all fields as an argument, so
that you can retrieve references/collections regardless of the field used for
the foreign key.
As a result, this procedure is less efficient (to some degree) then simple
select by pk. Hence, I decided to go with two different procedures. I'd like to
hear your suggestions for more efficient procedure implementation(s), if you
have any.
But ATM, I'd like to go with 2 procedures approach - as it allows for simplier
and more efficient select-by-pk procedure.
> Therefore, they are alike and you can use the same format as e.g.
> delete-procedure uses:
>
> <!ELEMENT delete-procedure
> (documentation?, (runtime-argument | constant-argument)*, attribute*)>
>
> If no runtime/constant arguments were given, then OJB uses the pk
> fields. This mapping is also already defined for the XDoclet tags
> so nothing new there. Btw, it also allows to use constant values if
> one so desires.
I still do not understand why would anybody need constant-argument. It is a
constant, right? So just write a constant into stored procedure itself if
desired so! :-) And runtime-argument actually does not provide a way to refer
to the runtime variable - all you can do is refer to the field. So its
functionality is limited to the renaming of the fields (which is: no
functionality).
More interesting will be to support JavaBean properties, so that you can pass
to the stored procedure some (really) runtime intformation. Just to give an
example:
/**
* @ojb.runtime-argument name="user"
* property="currentUser"
*/
public class Bean {
public String getCurrentUser() {
return context.getCallerPrincipal().getName();
}
}
Now, that could be more valuable then constant-argument.
> As for what is required for the XDoclet tags, the ojb.xml file
> is only for documentation purposes.
I'm sorry, my first patch was not properly created, it did not include patch to
*.xdt file - attached now as separate patch.
Thanks,
Vadim
> Support stored procedures in select by pk statement
> ---------------------------------------------------
>
> Key: OJB-16
> URL: http://issues.apache.org/jira/browse/OJB-16
> Project: OJB
> Type: New Feature
> Components: PB-API
> Versions: 1.0.x CVS
> Reporter: Vadim Gritsenko
> Attachments: SelectByPKProcedureDescriptor.java, db-ojb-selectbypk.diff,
> xdoclet.diff
>
> This patch adds support for retrieving objects by primary keys through call
> to stored procedure instead of using select statement.
> To activate the feature, add xdoclet tag to the class:
> /**
> * @ojb.class table="MYBEAN"
> * @ojb.selectbypk-procedure name="FIND_MYBEAN_BYID"
> */
> public class MyBean {
> /**
> * @ojb.field primarykey="true"
> */
> Integer id;
> }
> And then, create stored procedure:
> CREATE OR REPLACE PACKAGE TYPES AS
> TYPE CURSORTYPE IS REF CURSOR;
> END TYPES;
> /
> CREATE OR REPLACE FUNCTION FIND_MYBEAN_BYID (ANID IN MYBEAN.ID%TYPE)
> RETURN TYPES.CURSORTYPE AS
> RESULT TYPES.CURSORTYPE;
> BEGIN
> OPEN RESULT FOR SELECT * FROM MYBEAN WHERE ID = ANID;
> RETURN RESULT;
> END;
> /
> Patch is made against OJB_1_0_RELEASE branch.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
