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 <[email protected]>: > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel > ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
