I wanted to simplify the way of adding a turtle to a agent-set (not breed)
So I tried:
to join-turtles [a-set]
set a-set (turtle-set a-set self)
end
And then I could do:
ask some-turtle [join-turtles specific-set]
But it doesn't work. It appears to work inside the procedure but the set remains empty after the procedure.
Why? And how do I fix this?
The problem is the way that NetLogo deals with procedure arguments. Arguments are passed by value, not by reference, so when you change a-set within the procedure the change is made to the "copy" of the argument used by the procedure, not to the argument itself. In general, you cannot use a procedure to modify its arguments, procedures can only use them.
But, you could make your procedure a reporter, such as
to-report join-turtles [a-set]
set a-set (turtle-set a-set self)
report a-set
end
and then
ask target [set t-set join-turtles t-set]
I'm not sure how much of a simplification that would be, howerver.
Charles
Related
Here's the start of my typical stored procedure:
CREATE DEFINER=`joe`#`%` PROCEDURE `Add_Item`(
IN usernameApp VARCHAR(255),
IN barcodeApp VARCHAR(255),
IN quantityApp VARCHAR(255)
)
BEGIN
I would call it with something like this code from PHP:
CALL Add_Item('ethan', '987261826671', '12');
The issue is that I am looking for something a bit more dynamic, where I can call the stored procedure with parameters in any order (because I can't guarantee the order in my dynamic app I'm trying to create). I feel like named parameters would work, but I know MySQL doesn't have that for procedures.
Something like this would work, for example (pseudo code obviously):
CALL Add_Item(quantity>'12' name>'ethan', barcode>'987261826671');
Ideas?
Using PDO:
$sth = $dbh->prepare('CALL Add_Item(:quantity, :name, :barcode)');
// You can pass paremeters in any order here:
$sth->execute([
':quantity' => 12,
':name' => 'ethan',
':barcode' => '987261826671',
]);
The arguments to a stored proc are fixed. There are no optional arguments and the order is fixed. There's no such thing as named arguments like in Perl or Python.
A workaround you could do is the following:
SET #quantity = 12;
SET #name = 'ethan';
SET #barcode = '987261826671';
CALL Add_Item();
In other words, use session variables instead of procedure arguments. Then you can set the session variables in any order you want.
Session variables can be referenced within procedure code simply by using the # prefix. Session variables are visible only within the current session.
But this workaround doesn't work well for recursive procedures, where you want to pass parameters to the procedure in recursive calls.
Also, if you call the procedure multiple times during your session, you'd have to remember to change the values or else the values from prior calls could carry over to subsequent calls.
I have to say this is an odd question. Many programming languages, even PHP, require you to call a function or procedure with arguments in a specific order. This isn't too difficult a constraint.
I will make simpler than it is to get the answer I need without make you read a lot of code.
MySQL stored procedure:
CREATE PROCEDURE add_player
(IN name varchar(100),
IN isTrue boolean)
BEGIN
START TRANSACTION;
insert into tags (name,is_player) values (name,isTrue);
COMMIT;
END //
player_controller.rb
ActiveRecord::Base.connection.execute("call add_player('#{name}', #{is_player})")
Two problems I see(if you see more - say):
if name contains ' it breaks the call
sql injection - I don't use ? as parameters when I call the stored procedure. The reason is that it's just not working when I'm try with ?. I tried also change it to Player.where("add_player(?,?)",name,is_player)
Did you try something like this ?
ActiveRecord::Base.connection.execute("call add_player(#{ActiveRecord::Base.sanitize(name)}, #{is_player})")
There is another way suggested on the following SO link
using sanitize_sql_array to escape strings
The only problem is that sanitize_sql_array is not a public method
I wanted to create a new table, but I have a syntax error somewhere.
However I do not see where, no matter how often I look over it.
Can anybody spot my error?
Dim cmdCreate As New MySqlCommand("CREATE TABLE inout (inout_seacher TEXT,inout_guid TEXT,inout_blob LONGBLOB,inout_inouttype INTEGER,inout_automaticallyparsed TINYINT(1)," & _
"inout_price DOUBLE,inout_companyguid TEXT,inout_datetime TEXT,inout_title TEXT,inout_catid INTEGER,inout_vat INTEGER,inout_banktype INTEGER," & _
"inout_banktransferprice DOUBLE,inout_expenseinvoiceexistsinguid TEXT,inout_orderguid TEXT,inout_inoutsubtype INTEGER,inout_outinvoicetype INTEGER)", g_CnWebDB)
Thank you for the help!
Bad luck. Believe it or not 'inout' is a reserved word in MySQL. Either wrap it in backticks (`) or (better) call it something else. Also, are you sure you want DOUBLE and not DECIMAL?
"inout" is reserved word. Try other name for the table.
You can also quote the table's name using (), so (inout`) becomes acceptable.
As Strawberry already said, is a reserved word used for procedures; directly from MySQL.com:
As of MySQL 5.0.30, stored procedures that take no arguments can be
invoked without parentheses. That is, CALL p() and CALL p are
equivalent.
CALL can pass back values to its caller using parameters that are
declared as OUT or INOUT parameters. When the procedure returns, a
client program can also obtain the number of rows affected for the
final statement executed within the routine: At the SQL level, call
the ROW_COUNT() function; from the C API, call the
mysql_affected_rows() function.
I tried finding an answer to this online, but could not find any clear explanation:
Does the # in a stored procedure serve some sort of special purpose/signify something in particular? I am a little confused as to when we use it, since examples seem to vary on its usage.
For instance in the following example # is used:
DELIMITER $
DROP PROCEDURE IF EXISTS emp_count_2;
CREATE PROCEDURE emp_count_2(OUT param1 INT)
BEGIN
SELECT COUNT(*) INTO param1 FROM Employee;
END
$
DELIMITER ;
/* To invoke this procedure use the mysql command statement
CALL emp_count_2(#empCount);
SELECT #empCount;
*/
Once again, does the # in this example serve some sort of special purpose, or can we remove the # and just use normal variable names?
**EDIT: I am using MySql
The #variable syntax in MySQL denotes a user-defined session variable. You can set these user variables outside a stored procedure, but you can also set them inside a stored procedure, and the effect is that the variable retains the value after your procedure call returns.
So in your example, the following would also do the same thing:
CREATE PROCEDURE emp_count_2()
BEGIN
SELECT COUNT(*) INTO #empCount FROM Employee;
END
CALL emp_count_2(); /* sets #empCount as a side-effect */
SELECT #empCount;
It's okay for multiple sessions to set the user variable in this way concurrently, because user variables are scoped to a single session, and concurrent sessions may have variables of the same name, but with different values.
The variable syntax with no # prefix is for variables local to the procedure, either procedure parameters, or else local variables declared with DECLARE within the procedure body.
This usage you have, passing a user variable as a parameter and assigning it in the body of the procedure, is useful if you want to call a procedure several times and store the result in separate user variables. Otherwise each call to the procedure would overwrite the previous value in the #empCount user variable for the current session.
Inside my stored function I have :
formula := "(10+10 * 1000)/12";
(a simple math formula, with numbers only, dynamically created as a string)
How do I eval this, and return the result ?
I can't use EXECUTE (not possible inside a stored function) and if I make it a stored procedure and call it from a stored function, I get "Dynamic SQL is not allowed in stored function or trigger" -as if I would have the eval directly inside the function.
I need a stored function, and not a procedure, because I need to call it inside a SELECT statement.
I don't see what using the formula is buying you. If you're writing a stored procedure, type in the formula and forget the string.
I don't think it's in your interest to make the stored proc that dynamic where the formula being evaluated has to be changing from call to call.
If you must, you'll have to write a parser to break that string up into its constitutive parts, create a parse tree, and then walk the tree to evaluate it. It's not a trivial problem. I'd rethink this.
Apparently there is no solution to this.
I have applied a "paintfull" workaround in PHP, which I will not display here as it is not the subject of the question.