Development talk:DB layer 2.0 migration docs - Revision history

Stronk7: Development talk:dmllib 2.0 migration docs moved to Development talk:DB layer 2.0 migration docs

2008-07-25T17:14:42Z

Development talk:dmllib 2.0 migration docs moved to Development talk:DB layer 2.0 migration docs

← Older revision	Revision as of 17:14, 25 July 2008
(No difference)

Nicolasconnault: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

2008-07-22T03:26:25Z

Why / when do we '''have''' to use the params array in the "_sql" functions?

← Older revision		Revision as of 03:26, 22 July 2008
Line 42:		Line 42:
	:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Aha! So the purpose is to help make sure that dynamic data used in SQL searches is cleansed? Is that correct? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Aha! So the purpose is to help make sure that dynamic data used in SQL searches is cleansed? Is that correct? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
			::Yes, and to get rid of the troublesome stripslashes().
	# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?		# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?
	:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
	::Correct ~~on both counts~~ :) [[User:Nicolas Connault\|Nicolas Connault]] 22:24, 21 July 2008 (CDT)		::Correct :) [[User:Nicolas Connault\|Nicolas Connault]] 22:24, 21 July 2008 (CDT)

Nicolasconnault: Answering Mike

2008-07-22T03:24:53Z

Answering Mike

← Older revision		Revision as of 03:24, 22 July 2008
Line 45:		Line 45:
	:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
			::Correct on both counts :) [[User:Nicolas Connault\|Nicolas Connault]] 22:24, 21 July 2008 (CDT)

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

2008-07-22T02:32:20Z

Why / when do we '''have''' to use the params array in the "_sql" functions?

← Older revision		Revision as of 02:32, 22 July 2008
Line 41:		Line 41:
	# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?		# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?
	:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Aha! So the purpose is to help make sure that dynamic data used in SQL searches is cleansed? Is that correct?[[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Aha! So the purpose is to help make sure that dynamic data used in SQL searches is cleansed? Is that correct? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
	# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?		# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?
	:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist?[[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

2008-07-22T02:31:37Z

Why / when do we '''have''' to use the params array in the "_sql" functions?

← Older revision		Revision as of 02:31, 22 July 2008
Line 41:		Line 41:
	# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?		# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?
	:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
			:Aha! So the purpose is to help make sure that dynamic data used in SQL searches is cleansed? Is that correct?[[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
	# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?		# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?
	:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
			:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist?[[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)

Nicolasconnault: Answers to Sam's pertinent questions

2008-07-21T18:57:20Z

Answers to Sam's pertinent questions

← Older revision		Revision as of 18:57, 21 July 2008
Line 40:		Line 40:

	# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?		# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?
			:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?		# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?
			:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

2008-07-21T18:31:03Z

Why / when do we '''have''' to use the params array in the "_sql" functions?

← Older revision		Revision as of 18:31, 21 July 2008
Line 40:		Line 40:

	# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?		# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?

	# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?		# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

2008-07-21T18:30:51Z

Why / when do we '''have''' to use the params array in the "_sql" functions?

← Older revision		Revision as of 18:30, 21 July 2008
Line 39:		Line 39:
	== Why / when do we '''have''' to use the params array in the "_sql" functions? ==		== Why / when do we '''have''' to use the params array in the "_sql" functions? ==

	1. I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?		# I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?

	2. The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?		# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

2008-07-21T18:29:56Z

Why / when do we '''have''' to use the params array in the "_sql" functions?

← Older revision		Revision as of 18:29, 21 July 2008
Line 39:		Line 39:
	== Why / when do we '''have''' to use the params array in the "_sql" functions? ==		== Why / when do we '''have''' to use the params array in the "_sql" functions? ==

	I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?		1. I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?

			2. The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?

Mchurch: /* Why / when do we have to use the params array in the "_sql" functions? */

2008-07-21T18:10:25Z

Why / when do we *have* to use the params array in the "_sql" functions?

← Older revision		Revision as of 18:10, 21 July 2008
Line 37:		Line 37:
	[[User:sam marshall\|sam marshall]] 04:32, 3 June 2008 (CDT)		[[User:sam marshall\|sam marshall]] 04:32, 3 June 2008 (CDT)

	== Why / when do we have to use the params array in the "_sql" functions? ==		== Why / when do we '''have''' to use the params array in the "_sql" functions? ==

	I'm not sure I'm clear on what the advantages are in using the "params" array for the "_sql" functions (e.g. get_records_sql). Also, the text says we must* do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a must do or is it more of a can do?		I'm not sure I'm clear on what the advantages are in using the "params" array for the "*_sql" functions (e.g. get_records_sql). Also, the text says we '''must''' do it, but I see lots of examples in the already converted code where this hasn't been done. Is it really a '''must do''' or is it more of a '''can do'''?

← Older revision		Revision as of 03:26, 22 July 2008
Line 42:		Line 42:
	:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:You must always use the params array WHEN you have params to pass ;) If the SQL doesn't contain dynamic parameters (subject to SQL injection), we don't need the params array. [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Aha! So the purpose is to help make sure that dynamic data used in SQL searches is cleansed? Is that correct? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Aha! So the purpose is to help make sure that dynamic data used in SQL searches is cleansed? Is that correct? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
			::Yes, and to get rid of the troublesome stripslashes().
	# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?		# The new recordset handling seems odd. We used to use the "rs_fetch_next_record($rs)" function, which as I understood it was optimized so that the entire db records contents weren't stored in the PHP array variable. Now we are replacing it with a "foreach ($rs as $record)". Doesn't that mean that the entire data query results are stored in a PHP variable again?
	:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
	::Correct ~~on both counts~~ :) [[User:Nicolas Connault\|Nicolas Connault]] 22:24, 21 July 2008 (CDT)		::Correct :) [[User:Nicolas Connault\|Nicolas Connault]] 22:24, 21 July 2008 (CDT)

← Older revision		Revision as of 03:24, 22 July 2008
Line 45:		Line 45:
	:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)		:The new recordset uses a new feature of PHP5, the Iterator interface. Foreach can then be used on the recordset. (See the bottom of [http://phplens.com/adodb/code.initialization.html the adodb doc] for more info). [[User:Nicolas Connault\|Nicolas Connault]] 13:57, 21 July 2008 (CDT)
	:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)		:Hmmm... Looks like I need to spend some time learning PHP5's features. So, in PHP5, the "foreach" construct unlocks a classes' interator functions if they exist? [[User:Mike Churchward\|Mike Churchward]] 21:31, 21 July 2008 (CDT)
			::Correct on both counts :) [[User:Nicolas Connault\|Nicolas Connault]] 22:24, 21 July 2008 (CDT)

Development talk:DB layer 2.0 migration docs - Revision history

Stronk7: Development talk:dmllib 2.0 migration docs moved to Development talk:DB layer 2.0 migration docs

Nicolasconnault: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

Nicolasconnault: Answering Mike

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

Nicolasconnault: Answers to Sam's pertinent questions

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

Mchurch: /* Why / when do we '''have''' to use the params array in the "_sql" functions? */

Mchurch: /* Why / when do we *have* to use the params array in the "_sql" functions? */

Mchurch: /* Why / when do we have to use the params array in the "_sql" functions? */