Well, thats not really a use case. For instance what is the use case for stored procs in a relational db? While there are many, the primary ones are:
1. Transaction Management - Being able to manage the business logic around a transaction in order to maintain the integrity of the data in the database. 2. Security - Often DBAs will only allow access to stored procs as opposed direct access to tables. It makes security that much easier. 3. Reporting - Often an SQL statement is not enough for a report (maybe some switching logic or parameter logic) There are more use-cases, but these are some of the most common. Which of these apply to directories though? The other question relates to the interface. Applications which interact with databases are coded for a particuler schema (tables, views, stored procs...) and so its reasonable to make the application call a stored procedure. Applications which hit directories for information are generally coded to either the ldapv3 standard or for a particuler directory or even a directory instance. While the extended operation is a part of the ldapv3 standard, there aren't many applications that use them. Marc On 12/12/05, Ersin Er <[EMAIL PROTECTED]> wrote: > On 12/12/05, Marc Boorshtein <[EMAIL PROTECTED]> wrote: > > Interesting. So what use-cases currently exist for the "Extended > > Operation" model for Stored Procs in a directory? > > What ever you want.. For example, for some run time configurations, > for some administrative scripts for collecting some statistics.. There > can be much more.. > > > Marc > > > > On 12/12/05, Ersin Er <[EMAIL PROTECTED]> wrote: > > > On 12/12/05, Marc Boorshtein <[EMAIL PROTECTED]> wrote: > > > > Sorry, should have said "Stored Procedure" or script. Will the > > > > scripts be executed by a particuler operation (ie an add is executed > > > > which executes a script) or will it be executed manually by some > > > > external mechanism? > > > > > > Oh OK. Stored Procedures provide a great selection of usages. First > > > what we do to provide excutable code in the server is publishing these > > > stored procedures as extended operations. In fact we have only one > > > generic extended operation (say StoredProcedureExtendedOperation) > > > which accepts a call specification and executes the appropriate SP on > > > the server. Briefly, we are providing users the ability to "define > > > their own extended operations." > > > > > > SPs will also be used for Triggers. Triggers will be able to fire SPs > > > only. Say an Add operation will fire a SP (which will probably have to > > > implement an interface like AfterAddStoredProc) and appropriate > > > parameters in that context will be passed to the SP (via the method > > > forced by the interface). > > > > > > There are other usages of SP like scheduled tasks, etc. Finally I can > > > say that a stored procedure can be executed by a user or by an > > > operation automatically. This changes up to the context in which we > > > use them. But the Extended Operation mechanism is the main objective > > > now. > > > > > > Thanks for interest. > > > > > > > Marc > > > > > > > > On 12/12/05, Ersin Er <[EMAIL PROTECTED]> wrote: > > > > > On 12/12/05, Marc Boorshtein <[EMAIL PROTECTED]> wrote: > > > > > > Performance will probably be an issue with almost any scripting > > > > > > language that provides some more dynamic capabilities then java. > > > > > > > > > > Of course. Just trying to choose a reasoable one. > > > > > > > > > > > Also, what are you planning to use as the mapping model? For > > > > > > instance, will it be a single method for eac operation or a method > > > > > > for > > > > > > the input and one for the output? > > > > > > > > > > I'm not sure I exactly understand what you mean by mapping here. We > > > > > have DIT based Java classes whose only one static method can be called > > > > > as a stored procedure at a time. For scripting languages we may force > > > > > the script (again in the DIT) to have a function/method with certain > > > > > name (in case we cannot use reflection here) or we may use the script > > > > > as a whole. And for parameters we'll always use Java objects (and > > > > > primitives) and we will wrap them with any method required by the > > > > > scripting language and put in a context (as required by the scripting > > > > > language) to be passed to the script. > > > > > > > > > > > Marc > > > > > > > > > > > > On 12/12/05, Trustin Lee <[EMAIL PROTECTED]> wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > 2005/12/12, Ersin Er <[EMAIL PROTECTED]>: > > > > > > > > Hmm, OK. BeanShell seemed to be well integrated with Java but > > > > > > > > performance is an important aspect of our choice. We many > > > > > > > > consider > > > > > > > > using Mozilla Rhino. > > > > > > > > > > > > > > Rhino is a JavaScript engine with great performance and ease of > > > > > > > use, but > > > > > > > there's an issue with its license IIRC. There was a discussion > > > > > > > on Rhino in > > > > > > > [email protected], but this issue was not closed because > > > > > > > nobody gave > > > > > > > the bottom line. I don't think it is because this issue is > > > > > > > resolved; I've > > > > > > > been reading legal-discuss list since it had started. > > > > > > > > > > > > > > If license becomes a problem, we could just use Groovy, which is > > > > > > > more > > > > > > > attractive option for Java developers. > > > > > > > > > > > > > > HTH, > > > > > > > Trustin > > > > > > > -- > > > > > > > what we call human nature is actually human habit > > > > > > > -- > > > > > > > http://gleamynode.net/ > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ersin > > > > > > > > > > > > > > > > > > -- > > > Ersin > > > > > > > > -- > Ersin >
