[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: DB company default_language
- Subject: Re: DB company default_language
- From: Chris Travers <..hidden..>
- Date: Tue, 22 Nov 2011 15:20:34 -0800
On Tue, Nov 22, 2011 at 1:25 PM, herman vierendeels
> Hi Chris,
> There already is a field language_code in entity_credit_account.
> But there is something i do not understand in
> CREATE OR REPLACE FUNCTION entity_credit_save
> all parameters have a name structure like in_fieldname
> except in_language
> May i not change in_language to in_language_code ?
Sure, change this. Just make sure that any related inputs are renamed
or created with the name minus the in_ prefix.
> Should we also not define language_code in entity_credit_account as:
> in_language_code varchar(6) with default 'en_US' references
> language(code) on delete SET DEFAULT
> As we are discussing web-services, fat client <--> api-layer <--> fat
> DB-function, we should protect
> db-fields as much as possible , are we not ?
The procedural API is how the db is encapsulated. I think *most* fat
clients should go through the db API directly (for example, web
services to a POS terminal adds complexity and latency into a very
There are however a number of use cases where web services beat the db api....
Hope this makes sense.