Re: future coding standards for stored procedure names

[herman vierendeels <..hidden..>]

Hi Chris,

This is a bit new to me.
Could you tell a little more about the function of a separator in a
stored_procedure name?
Is this separator meant to be interpreted in pre-db code or in the db itself?

Object oriented guys would prefer object->method syntax.

Thanks,
Herman



2011/11/25 Chris Travers <..hidden..>:
> Hi;
>
> I am thinking one area we probably want to firm up our coding
> standards is in the area of stored procedure names.  There are two
> fundamental issues I see with our current approach in 1.3.  The first
> is that the double underscore approach really doesn't work well except
> in the case of roles where it is enforced by the application.  The
> second is that verbs end up going wherever they seem like they should,
> and this makes the API somewhat hard to learn.
>
> I would suggest instead think about this and try to standardize as
> much as possible going forward, at least into 1.4.
>
> Basically I think we should standardize on one of the following two formats:
>
> ${class_name}_${sep}_${noun}_${verb}
>
> or
>
> ${class_name}_${sep}_${verb}_${noun}
>
> This leads to two questions:
>
> 1)  Which of these is preferred?  I am leaning towards the second
> because it suggests a sort of Subject-Verb-Object syntax relatively
> familiar to us Indo-European speakers (languages which include
> English, Spanish, etc).  In cases where the second noun doesn't apply,
> it's pretty clear also.  So for example company_pkg_get (with pkg as
> the $sep) is clear, as is company_pkg_get_credit_accts.  Here we know
> we have a company and we are getting related credit accounts.
>
> 2)  What kidns of separators should we use?  One option might be to
> look at non-alphanumeric characters that could be differentiated by by
> sight, something like:
>
> "company_:::_get"
>
> The big issue here is that omitting the double quotes renders this
> unusable and this makes manual use a little more bothersome, and this
> could lead to dangerous errors if new operators are ever added which
> conflict with the choices made.  However if we go with this route, we
> can remove the underscores around sep, leading to something like
> "company:::get" or "company->get"
>
> The second possibility is to use an alphanumeric string to
> separate.the components.  Say, pkg in the above example.
>
> I am personally leaning towards the "company->get" syntax (and
> "company->get_credit_accounts").  I think it is the easiest to read,
> and most frameworks are likely to automatically quote the identifier
> anyway.
>
> What does everyone else think?
>
> Best Wishes,
> Chris Travers
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure
> contains a definitive record of customers, application performance,
> security threats, fraudulent activity, and more. Splunk takes this
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
>