Language and development rules - Revision history

Eldy: /* Closure or anonymous function */

2026-10-13T02:15:41Z

Closure or anonymous function

← Older revision		Revision as of 02:15, 13 October 2026
Line 70:		Line 70:
	====Closure or anonymous function====		====Closure or anonymous function====
	If you new a function, just create a real one (or a method).		If you new a function, just create a real one (or a method).
	Anonymous function are just forbidden (existing one should be removed), they brings a lot of problem:		Anonymous function are just '''forbidden''' (existing one should be removed), they brings a lot of problem:
	* Code readability		* Code readability
			* $tihs can create cyclic reference.
	* Broken static analytics tools that can't guess type or path of variable		* Broken static analytics tools that can't guess type or path of variable
	* ~~Function documentation~~		* Unit test more difficult
	* AI become crazy		* AI become crazy
	* Coding debug trouble		* Coding debug trouble (no name function into stack trace)
	* Impact analysis more difficult as the stack trace of code can't be guess easily when function are not named explicitely.		* Impact analysis more difficult as the stack trace of code can't be guess easily when function are not named explicitely.
			* Memory overload not under control.

	====Comments====		====Comments====

Eldy: /* PHP */

2026-10-13T02:11:54Z

PHP

← Older revision		Revision as of 02:11, 13 October 2026
Line 68:		Line 68:
	</syntaxhighlight>		</syntaxhighlight>

	~~<br />~~		====Closure or anonymous function====
			If you new a function, just create a real one (or a method).
			Anonymous function are just forbidden (existing one should be removed), they brings a lot of problem:
			* Code readability
			* Broken static analytics tools that can't guess type or path of variable
			* Function documentation
			* AI become crazy
			* Coding debug trouble
			* Impact analysis more difficult as the stack trace of code can't be guess easily when function are not named explicitely.

	====Comments====		====Comments====

Eldy: /* Dates and Timezones */

2026-09-20T11:48:19Z

Dates and Timezones

← Older revision		Revision as of 11:48, 20 September 2026
Line 501:		Line 501:
	And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer.		And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer.

	'''How to manage ~~this for date~~ with no hours:'''		'''How to manage dates with no hours (just day):'''

	For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'.		For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'.

Eldy: /* Dates and Timezones */

2026-09-20T11:47:20Z

Dates and Timezones

← Older revision		Revision as of 11:47, 20 September 2026
Line 507:		Line 507:
	And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101000000') by using $db->jdate(..., 'gmt');		And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101000000') by using $db->jdate(..., 'gmt');

			'''Other cases'''
	Other cases

	*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date. Try to never rely on this field in Dolibarr (this autoupdate field is mostly for debug purpose).		*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date. Try to never rely on this field in Dolibarr (this autoupdate field is mostly for debug purpose).

Eldy: /* Dates and Timezones */

2026-09-20T11:47:06Z

Dates and Timezones

← Older revision		Revision as of 11:47, 20 September 2026
Line 495:		Line 495:
	For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value integer 7200 (2 * 3600s) and will be submitted into a SQL request to database into the string '19700101030000' (PHP convert the int into its TZ hour and database will unconvert it using its timezone too that is same than PHP).		For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value integer 7200 (2 * 3600s) and will be submitted into a SQL request to database into the string '19700101030000' (PHP convert the int into its TZ hour and database will unconvert it using its timezone too that is same than PHP).

	How to manage this for date with hours:		'''How to manage this for date with hours:'''

	So all insert or update methods must convert, during generation of SQL request, the integer memory date into a db string by using db->idate (you may find examples into skeleton).		So all insert or update methods must convert, during generation of SQL request, the integer memory date into a db string by using db->idate (you may find examples into skeleton).
Line 501:		Line 501:
	And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer.		And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer.

	How to manage this for date with no hours:		'''How to manage this for date with no hours:'''

	For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'.		For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'.

Eldy: /* Dates and Timezones */

2026-09-20T11:46:45Z

Dates and Timezones

← Older revision		Revision as of 11:46, 20 September 2026
Line 491:		Line 491:

	*A date into memory must always be stored with Timestamp GMT format.		*A date into memory must always be stored with Timestamp GMT format.
	*A date stored into database, is the GMT Timestamp of date submitted into the request usng the <b>PHP server</b> timezone. This does not apply to date ~~update~~ automatically by database (fields '''tms''' into database).		*A date stored into database, is the GMT Timestamp of date submitted into the request usng the <b>PHP server</b> timezone. This does not apply to date updated automatically by the database engine (fields '''tms''' into database).

	For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value 7200 and will be submitted into a SQL request to database ~~with~~ the string '19700101030000' (PHP convert into its TZ hour and database will unconvert it using its timezone too that is same than PHP).		For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value integer 7200 (2 * 3600s) and will be submitted into a SQL request to database into the string '19700101030000' (PHP convert the int into its TZ hour and database will unconvert it using its timezone too that is same than PHP).

	~~All select methods should translate~~ date ~~fields, that are~~ with format TZ of database ('19700101030000'), into a timestamp field by calling the method db->jdate. This is to store into memory a GTM Timestamp date. All insert methods must convert, during generation of SQL request, the memory date into the string by using db->idate (you may find examples into skeleton).		How to manage this for date with hours:

	*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date.		So all insert or update methods must convert, during generation of SQL request, the integer memory date into a db string by using db->idate (you may find examples into skeleton).

			And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer.

			How to manage this for date with no hours:

			For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'.

			And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101000000') by using $db->jdate(..., 'gmt');


			Other cases

			*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date. Try to never rely on this field in Dolibarr (this autoupdate field is mostly for debug purpose).

	*Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''.		*Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''.

Eldy: /* Dates and Timezones */

2026-09-20T11:34:29Z

Dates and Timezones

← Older revision		Revision as of 11:34, 20 September 2026
Line 497:		Line 497:
	All select methods should translate date fields, that are with format TZ of database ('19700101030000'), into a timestamp field by calling the method db->jdate. This is to store into memory a GTM Timestamp date. All insert methods must convert, during generation of SQL request, the memory date into the string by using db->idate (you may find examples into skeleton).		All select methods should translate date fields, that are with format TZ of database ('19700101030000'), into a timestamp field by calling the method db->jdate. This is to store into memory a GTM Timestamp date. All insert methods must convert, during generation of SQL request, the memory date into the string by using db->idate (you may find examples into skeleton).

	*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp ~~GMT~~ of date when change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date.		*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date.

	*Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''.		*Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''.

Eldy: /* Foreign keys */

2026-08-04T14:33:38Z

Foreign keys

← Older revision		Revision as of 14:33, 4 August 2026
Line 246:		Line 246:

	==Foreign keys==		==Foreign keys==
	~~Name~~ of a foreign key must start with the prefix <tt>fk_</tt> followed by the table name (i.e. name of the referencing table) (this is required to avoid duplicate names in project that are not allowed even if in different tables by some DBMS like Postgresql) then the field name (i.e. name of the referencing field) (this is to allow to have several foreign keys in same table).		The name of a foreign key must start with the prefix <tt>fk_</tt> followed by the table name (i.e. name of the referencing table) (this is required to avoid duplicate names in project that are not allowed even if in different tables by some DBMS like Postgresql) then the field name (i.e. name of the referencing field) (this is to allow to have several foreign keys in same table).

	Example:		Example:
	''fk_facture_fourn_fk_soc'' is a foreign key in the table llx_facture_fourn for the field fk_soc in this table (that references the rowid field in another table)		''fk_facture_fourn_fk_soc'' is a foreign key in the table llx_facture_fourn for the field fk_soc in this table (that references the rowid field in another table)

	Note: If you develop your own external module, it must have no hard foreign keys that point to Dolibarr standard tables. This will break standard dolibarr upgrades, repair, backup and restore tools and may also break standard features. Foreign keys must be soft foreign keys so managed by the code with no database contraints.		Note when using a foreing key:
			- Do not add a hard foreign key (a foreign key controled bydatabase) when the link is not important. This generates more trouble than solution. For exemple, a link to a user table to follow the author of creation of an object is NOT an important link. If parent object,the user, is deleted,the child record will be orphelin but this is not a problem. Record will appear with a cretion author that is "unknown" and that is the truth if we have deleted the parent user.

			- If you develop your own external module, it must have no hard foreign keys that point to Dolibarr standard tables. This will break standard dolibarr upgrades, repair, backup and restore tools and may also break standard features. Foreign keys must be soft foreign keys so managed by the code with no database contraints.

	==Alternative keys==		==Alternative keys==

Houblon: /* Denormalized field */

2026-05-09T14:56:16Z

Denormalized field

← Older revision		Revision as of 14:56, 9 May 2026
Line 269:		Line 269:
	In such a case, to allow developper to understand that the data is not the value that rule, we must prefix the nameof fiel with '''"denormalized_"'''.		In such a case, to allow developper to understand that the data is not the value that rule, we must prefix the nameof fiel with '''"denormalized_"'''.

	For example the field "denormalized_lower_planned_end_date" to store the ending date of the last membership of a member. We already have the information, but doing search or filter on it is difficult as it is ~~store~~ into ~~a nother~~ table into another level, so we can duplicate the information into a such field.		For example the field "denormalized_lower_planned_end_date" to store the ending date of the last membership of a member. We already have the information, but doing search or filter on it is difficult as it is stored into another table into another level, so we can duplicate the information into a such field.

	If this happen, we must :		If this happen, we must :
	* check the any import profile has a function to update the denormalized value during import.		* check the any import profile has a function to update the denormalized value during import.
	* have a ~~taks~~ in the repair.php to recalculate the value and align the data with the original source.		* have a task in the repair.php to recalculate the value and align the data with the original source.
	* into the crud method that update any data that impact the field, we must include the update or the denormalized value.		* into the crud method that update any data that impact the field, we must include the update or the denormalized value.

Eldy: /* Denormalized field */

2026-05-07T12:54:01Z

Denormalized field

← Older revision		Revision as of 12:54, 7 May 2026
Line 274:		Line 274:
	* check the any import profile has a function to update the denormalized value during import.		* check the any import profile has a function to update the denormalized value during import.
	* have a taks in the repair.php to recalculate the value and align the data with the original source.		* have a taks in the repair.php to recalculate the value and align the data with the original source.
			* into the crud method that update any data that impact the field, we must include the update or the denormalized value.

	==SQL Coding rules==		==SQL Coding rules==