Mudança para Mysqli

[marxrtf 2]

Boa noite, estou fazendo aos poucos uma migração do meu sistema de Mysql_ para Mysqli, ainda estou trombando em detalhes até simples, outros nem sei. Mas estou lendo algumas coisas e o manual do Beraldo para isso. Como deixei programação um pouco de lado, mas dependo deste sistema ainda, preciso de fazer essa migração para não complicar logo a frente.

 

Neste campo que é um droplist de Sexo, não estou conseguindo ter o entendimento.

<select name="sexo">
<? $sql_sexo = mysql_query("SELECT * FROM sexos ORDER BY id_sexo ASC");
while($coluna = mysql_fetch_array($sql_sexo)) { ?><option value="<?=$coluna[sexo]?>"<? if(@mysql_result($sql,0,sexo) == $coluna[sexo]) echo " selected"; ?>><?=$coluna[sexo]?></option>
<? } ?></select>

Acho que no select eu faria assim: Mas no restante estou na dúvida

$sql_sexo = $sqli->query("SELECT * FROM sexos ORDER BY id_sexo ASC");

Abaixo no result a dúvida que seria a mesma de cima basicamente

<td width="190"><input name="nome" type="text" value="<?=@mysql_result($sql,0,nome)?>" size="60" onkeyup="up(this)"></td>

[Beraldo 864]

Dê uma olhada neste artigo passo-a-passo: http://rberaldo.com.br/como-atualizar-php-mysql-mysqli/

[marxrtf 2]

Sim, esse mesmo é o manual que estou lendo seu e mencionei. Algumas coisas já consegui fazer mudanças. Nesta parte que postei que não consegui o entendimento.

[marxrtf 2]

A minha dúvida está sendo neste if

<? if(@mysql_result($sql,0,sexo) ==

[Beraldo 864]

pelo que sei, não existe um exato equivalente ao mysql_result. É melhor você usar fetch_ e depois usar o elemento do array no if

[marxrtf 2]

Bom, como não estou na ativa mais em programação, irei deixar o sistema de lado com o tempo. Conversei com um programador que está bem atualizado. Ele só me falou o certo: Desenvolve um do zero que é mais simples, porque migrar é dor de cabeça. Pura verdade, mesmo eu aqui tentando aos poucos, vejo que se pensar em PDO fica muito pior, já que para o mysqli já são muitas diferenças. Não é simples como se fala. Sisteminha ou site de 10 arquivos pode ser simples, mas pegar um sistema mais robusto e com centenas de arquivos. Vai penar.

 

Creio que para quem está super atualizado pode ter sua facilidade, mas em sua maioria não está. Por isso ele falou uma coisa certa: Se você quer ficar com esse seu sistema Mysql_ por mais 4 ou 5 anos, fique tranquilo. As hospedagens não vão largar o osso do php 5.x tão cedo. Largar é perder $$$

 

PhP 7 ainda é para inglês ver no momento e por algum tempo.

 

No meu caso estou com ele, pois só devo ficar com esse sistema no mais uns dois anos ou três na pior das hipóteses

.

[Gabriel Heming 766]

http://stackoverflow.com/a/13764884

 

http://php.net/manual/en/function.mysql-result.php#116670

 

Em sistemas grandes, normalmente utiliza-se de um "ecossistema" para resolver inúmeros problemas. Alguns estes problemas são desenvolvimento contínuo e interoperabilidade.

 

Normalmente, conexões com o SGBD são abstraídas através de uma interface. Toda e qualquer mudança a longo prazo, fica imperceptível através desta interface.

[marxrtf 2]

As mudanças que fiz fica assim, e no cadastro está ok. Dessa forma eu consigo cadastrar.

<select name="sexo">
<? $sql_sexo = $sqli->query("SELECT * FROM sexos ORDER BY id_sexo ASC");
while ($coluna = $sql_sexo->fetch_assoc()) { ?><option value="<?= $coluna['sexo'] ?>"><?= $coluna['sexo'] ?></option>
 <?php } ?></select>

Até aí beleza, mas quando preciso editar vem o pepino para mim. já tentei algumas coisas mas o conhecimento ali parou. aonde tem o mysql_result é que da erro, e eu não sei ali o que alterar para o mysqli.

<select name="sexo">
<? $sql_sexo = $sqli->query("SELECT * FROM sexos ORDER BY id_sexo ASC");
while ($coluna = $sql_sexo->fetch_assoc()) { ?><option value="<?=$coluna[sexo]?>"<? if(@mysql_result($sql,0,sexo) == $coluna[sexo]) echo " selected"; ?>><?=$coluna[sexo]?></option>
<? } ?></select>

Então esta linha abaixo é que não estou entendendo como alterar. É a parte que traz o resultado, No no mysql_ funciona perfeitamente tudo, apenas para altetar para o mysqli que não sei o que alterar ali

<? if(@mysql_result($sql,0,sexo) == $coluna[sexo]) echo " selected"; ?>

[Gabriel Heming 766]

Em ambos os links, do post #7, há bons substitutos ao uso da função. O que você não está conseguindo implementar?

Até o momento não vimos novas tentativas de implementação.

[marxrtf 2]

Gabriel, me desculpe. Se você não leu desde o começo para ver o que foi mudado.

 

Abaixo o que estava original no post #1

<select name="sexo">
<? $sql_sexo = mysql_query("SELECT * FROM sexos ORDER BY id_sexo ASC");
while($coluna = mysql_fetch_array($sql_sexo)) { ?><option value="<?=$coluna[sexo]?>"<? if(@mysql_result($sql,0,sexo) == $coluna[sexo]) echo " selected"; ?>><?=$coluna[sexo]?></option>
<? } ?></select>

A mudança que você diz não ter visto no post #7

<select name="sexo">
<? $sql_sexo = $sqli->query("SELECT * FROM sexos ORDER BY id_sexo ASC");
while ($coluna = $sql_sexo->fetch_assoc()) { ?><option value="<?=$coluna[sexo]?>"<? if(@mysql_result($sql,0,sexo) == $coluna[sexo]) echo " selected"; ?>><?=$coluna[sexo]?></option>
<? } ?></select>

Se for observar se tem mudanças de mysql_ para o mysqli

 

No caso para cadastro foi resolvido assim:

<select name="sexo">
<? $sql_sexo = $sqli->query("SELECT * FROM sexos ORDER BY id_sexo ASC");
while ($coluna = $sql_sexo->fetch_assoc()) { ?><option value="<?= $coluna['sexo'] ?>"><?= $coluna['sexo'] ?></option>
 <?php } ?></select>

Mas para edição eu tenho de trazer o valor marcado, no caso no mysql_ estava tranquilo, mas no mysqli tem a linha adicional abaixo que eu não soube como modificar.

<? if(@mysql_result($sql,0,sexo) == $coluna[sexo]) echo " selected"; ?>

Tentei de uma forma fazendo uma consulta e no droplist fazendo como abaixo. Ele me traz o sexo desejado, porém ele me duplica o sexo. Se vem marcado HOMEM, ele me lista HOMEM e HOMEM, não me trazendo o resulta MULHER para alteração

<select name="sexo">
<? $sql_sexo = $sqli->query("SELECT * FROM sexos ORDER BY id_sexo ASC");
while ($coluna = $sql_sexo->fetch_assoc()) { ?><option value="<?= $coluna['sexo'] ?>"><?php echo $sexo;?></option>
 <?php } ?></select>

Então desculpe se você não viu novas tentativas, até porque até agora ninguém postou uma linha para eu ver o que eu poderia alterar. Mesmo sendo moderador se pode errar, então ler um tópico do começo ajuda para ver se houve alterações ou mudanças do código. Você leu o post #7 e não foi ver o post #1 para ver se tinha diferença do 1 para o 7.

[Gabriel Heming 766]

O que nós, como voluntários, esperamos. É que você veja os exemplos apresentados, e tente implementar. Uma vez que não conseguir, traga sua implementação que lhe orientaremos.

 

Novamente, reitero, nenhuma novidade quanto ao código sobre mysql_result.

 

Atente aos links acima postados (copiados agora aqui para baixo), a dois bons exemplos:

http://php.net/manual/en/function.mysql-result.php#116670

http://stackoverflow.com/questions/2089590/mysqli-equivalent-of-mysql-result/13764884#13764884

 

Lá, no link do manual, logo acima, há descrito o seguinte:

 

Warning

This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information. Alternatives to this function include:

• mysqli_data_seek() in conjunction with mysqli_field_seek() and mysqli_fetch_field()
• PDOStatement::fetchColumn()

 

Conforme descrito acima, no manual do PHP, a função mysql_result pode ser substituída pelo uso de mysqli_data_seek em conjunto de mysqli_field_seek e mysqli_fetch_field.

 

É nesse momento que eu questiono (exatamente o questionamento do post #9), o que, até o momento, você implementou usando essas três funções?

 

Repito, nos links acima adicionados, existe o exemplo perfeitamente funcional sobre a substituição de mysql_result utilizando mysqli_*. Ou seja, qual a sua dificuldade em implementar a substituição?

 

A partir desse questionamento, poderemos lhe orientar como proceder. O que não faremos é lhe entregar a resposta pronta (apesar de estar pronta nos links apresentados).

[marxrtf 2]

Gabriel, até o momento não pedi resposta pronta se é isso que diz. Até porque o que mudei não foi conseguido uma linha aqui sequer no tópico.

 

Sobre nenhuma novidade sobre o mysql_result, por isso o pedido de uma solução mais viável e limpa. O grande problema de migrar do mysql_ para o mysqli_ é justamente um pouco da complexidade em quem não está totalmente atualizado.

 

a mudança em todo um sistema não é simples, e por vezes vamos esbarrando em coisas simples e até resolvendo coisas mais difíceis. Na maioria quando você tem uma linha no mysql_, quando se migra para o mysqli_ você tem de reescrever várias linhas.Se pode falar tudo, mas a mudança faz crescer seu código em 200% O que você tinha no mysql_ bem feito em uma linha, como o mysqli_ você para obter o mesmo resultado tem que criar 3,4,5...

 

Apesar de não estar totalmente atualizado na função, leio muita coisa a respeito. Inclusive se você pesquisar a fundo vai ver que tornar a extensão mysql_ obsoleta no php 7 não foi maioria nem na equipe do php que decidiu isso

 

Inclusive essa parte dos que não foram a favor, foram criteriosos que a o mysql_ era totalmente funcional e seguro. para se tornar obsoleta. A medida foi muito mais marketeira e $$$.

 

Forçar grandes empresas a trocar de sistemas ou reescrever códigos, alavancar novos cursos e ensino nos novos padrões, entre outras dezenas de coisas que envolvem $$$$ mundo a fora.

 

Mas é isso.

 

Quanto a solução do meu problema. Já consegui uma solução alternativa, mas que está e vai ficar funcional.

 

Grande Abraço.

[Gabriel Heming 766]

Todos os seus questionamentos sobre a mysql_ functions são respondidos aqui:

http://stackoverflow.com/a/12860046

 

Isso faz parte da evolução de software.

 

Funcional e seguro? Isso não é a mais de anos. Ficou mais evidente com o lançamento do PHP 5.3 (30 Jun 2009).

 

Existe ainda um gráfico (o qual não estou localizando) que mostra a quantidade de projetos de código aberto que ainda utilizam a função. Se não me engano, eram menos de 1% (0,5% para ser preciso). Ou seja, era necessário manter a compatibilidade de código com uma função cheia de problemas para menos de 0,5%?

 

PHP não perde dinheiro algum, nem ganha nada com isso, é um projeto open-source. Quem perde são os programadores que não pretendem se atualizar.

 

E ainda mais, quem ganha são os servidores que pegam a fatia de programadores não dedicados com a evolução de software.

[marxrtf 2]

Se você diz, então pergunta a equipe do php que foi contra porque falaram isso. Você estava na decisão de desativar a extensão mysql_ na versão 7 do php?

 

Acho que você não está a par disso, procure bem se você tiver acesso. Quem decidiu isso foram pouco mais de 40 pessoas, no qual mais de 1/3 era contra ao que comentei.Foram claros que seguindo algumas definições de segurança, não tinha porque o remover.

 

Mas se a maioria disse sim, fazer o que.

 

Estranho esse fórum ou alguns membros dele não conseguir ter acesso a essa informação

[marxrtf 2]

Resolvido. Consegui uma solução.

[Gabriel Heming 766]

Não gostaria de dar continuidade a discussão, mas é importante deixas claro. Até porque, essas threads ficarão por muito tempo aqui e é importante que quando alguém ler, saiba todos os lados para entender o porque das mudanças.

 

Nas suas afirmações, você está vendo apenas um lado (e falando algo sobre dinheiro e marketing que nem existe). Estou te apresentando ambos, tire suas próprias conclusões:

 

Votação:

A votação necessitava de 2/3, conseguiram mais 28 contra 12 (mais de 2/3 de 40). Ou seja, menos de 1/3 votou para manter a biblioteca. O que é muito menos do pessoal que votou para manter a linguagem estagnada sem maior suporte OO. Um dos que votou, é o Guilherme Blanco, veja a palestra dele no PHP Experience 2016, promovido pelo iMasters, ele fala sobre o PHP 7 e um pouco sobre as remoções das extensões (apenas um pouco, mas é o suficiente).

 

Evolução do PHP:

Sim, leio regularmente as RFCs, e reitero, foi um grande avanço. O PHP 7 é um divisor de águas, foi desenvolvido para deixar de lado uma arquitetura ultrapassada e utilizar os recursos mais recentes em prol da performance e boas práticas. Por isso o core se chama PHP Next Generation

 

Estagnação da biblioteca ext/mysql:

A ext/mysql (também conhecida como MySQL Client Library) era apenas uma biblioteca sem atualização, proprietária mysql (agora Oracle), que dependia de detalhes que fugiam do escopo do desenvolvimento.

 

A equipe da ext/mysql, não se deu ao trabalhado nem de dar suporte a prepared statements (suporte oferecido pelo MySQL mas não pela API). Não possui suporte multi statements, transactions, stored procedures, entre outros detalhes que todos os bancos de dados provêm.

 

Afinal, não dá nem suporte completo ao MySQL 5.1, lançado em 2004. (e isso que estamos na versão 5.7). Ou seja, 12 anos sem suporte completo ao MySQL.

 

Mas essa não é toda a realidade, veja bem:

This is the original extension designed to allow you to develop PHP applications that interact with a MySQL database. The mysql extension provides a procedural interface and is intended for use only with MySQL versions older than 4.1.3. This extension can be used with versions of MySQL 4.1.3 or newer, but not all of the latest MySQL server features will be available.

 

O MySQL 4.1.3 foi lançado em conjunto com o MySQL 5.1, dessa forma, a API ficou estagnada, também, para as posteriores versões 4 do MySQL.

 

Nessa época, MySQL era o banco de dados mais odiado por programadores não PHP (sim, eu já havia adentrado na programação nessa época por curiosidade de pré-adolescente).

 

Mais descrição sobre ext/mysql:

 

The older MySQL Client Library was written by MySQL AB (now Oracle Corporation) and so was released under the MySQL license. This ultimately led to MySQL support being disabled by default in PHP. However, the MySQL Native Driver has been developed as part of the PHP project, and is therefore released under the PHP license. This removes licensing issues that have been problematic in the past.

 

Antigamente, não era nem possível rodar o PHP sem ter mysql, por causa da ext/mysql:

 

Also, in the past, you needed to build the MySQL database extensions against a copy of the MySQL Client Library. This typically meant you needed to have MySQL installed on a machine where you were building the PHP source code. Also, when your PHP application was running, the MySQL database extensions would call down to the MySQL Client library file at run time, so the file needed to be installed on your system. With MySQL Native Driver that is no longer the case as it is included as part of the standard distribution. So you do not need MySQL installed in order to build PHP or run PHP database applications.

 

Outro perda do antigo driver (ou ganho dos novos), é o consumo elevado e desnecessário de memória:

 

One example of the memory efficiency is the fact that when using the MySQL Client Library, each row is stored in memory twice, whereas with the MySQL Native Driver each row is only stored once in memory.

 

Do site da própria MySQL:

 

PHP MySQL extensions

The PHP MySQL extensions are lightweight wrappers on top of a C client library. There are 3 PHP MySQL extensions:

• ext/mysql (not recommended)
• ext/mysqli
• PDO_MySQL

 

A comunidade PHP:

A comunidade se deu ao trabalho de desenvolver a mysqlnd e PDO_MySQL, pois uma equipe externa não conseguia fazer isso. Acha certo manter algo ultrapassado em uma linguagem de constante evolução?

 

Poll:

O sistema de 2/3 já é usado para evitar discussões como essa, pois na comunidade do PHP vai ter quem vá defender que tudo seja mantido por compatibilidade. Veja a discussão que eu tive, e mais três desenvolvedores, no PHP Bug. A discussão foi sobre um erro de programação, que era exatamente um erro, e que apenas um dos desenvolvedores não queria alterar ele, pois, segundo ele, haveria uma quebra grande de compatibilidade e era mais seguro alterar a documentação para o tipo errado.

 

Removeram bibliotecas que não eram atualizadas a mais de 10 anos, e ainda houve quem votasse contra, pois poderia quebrar a compatibilidade. Pois bem, ninguém utilizava essas bibliotecas.

 

Ainda estão votando contra tipagem de propriedades, sendo que é uma questão opcional. Da mesma forma que um script pode ser strict para type hints e retornos, a tipagem de propriedades também pode ser. Mas ainda não chegaram a um consenso sobre isso. Algo que acontecerá em breve.

 

Reitero, leia atentamente todos os pontos de vista. Quer uma evolução, alguém vai ter que mudar, e que seja em prol da boa promação.