[Mandrack_FreeZe]

PGConnector - Manipulaзгo do SGBD PostgreSQL para SA-MP

Boa noite pessoal. Apуs muito tempo inativo da comunidade SA-MP resolvi desenvolver essa Plugin. Eu sei que existem outras que fazem a mesma funзгo que essa porйm desenvolvi a mesma para fins de conhecimentos na linguagem C++. Fico no aguardo de sugestхes e possнvel bugs.

A plugin tem suporte a querys assнncronas e sincronas e atualmente tem suporte aos sistemas operacionais Windows e Linux. A mesma suporta administrar atй 50 conexхes simultвneas (no futuro pretendo criar um arquivo de configuraзгo para administrar estes tipos de parвmetros). Ainda tem alguns pontos nela que podem ser melhorados como a manipulaзгo da memуria e atй o desempenho. Em uma versгo futura irei disponibilizar melhorias nesses quesitos porйm por hora a mesma estб utilizбvel.

A plugin estб disponнvel no GitHub e o tutorial de como instalar a mesma estб disponнvel la tambйm. Espero ela seja ъtil para quem tem interesse em usar esse SGBD e que possa ser usada como objeto de estudo por todos assim como serviu para mim. Em caso de dъvidas/sugestхes/erros й sу deixar um comentбrio.

Aqui segue uma lista de todos os comandos e forwards:

pawn Код:

//Nativas responsбveis pela manipulaзгo das conexхes
native PG_conectar(host[], porta[], usuario[], senha[], database[]);
native PG_encerrarConexao(idConexao);
native PG_status(idConexao);
native PG_ultimoErro(idConexao, strErro[], sizeofStrErro);
native PG_setClientEncode(idConexao, encode[] = "WIN1252");
native PG_escapeString(idConexao, strOrigem[], strDestino[], sizeofStrDestino);

//Nativas responsбveis pela manipulaзгo de respostas
native PG_query(idConexao, query[]);
native PG_assyncQuery(idConexao, query[], callbackFunction[]);
native PG_statusResposta(idResposta);
native PG_erroResposta(idResposta, strErro[], sizeofStrErro);
native PG_liberarResposta(idResposta);
native PG_quantidadeColunas(idResultado);
native PG_quantidadeLinhas(idResultado);
native PG_recuperarInt(idResultado, linha, coluna);
native Float:PG_recuperarFloat(idResultado, linha, coluna);
native PG_recuperarStr(idResultado, linha, coluna, strValor[], sizeofStrValor);
native PG_verificarNulo(idResultado, linha, coluna);

//Forwards
forward OnPostgreSQLError(errorCode, erro[]);

Para ver a explicaзгo detalhada e exemplos de como utilizar cada comando acesse a pбgina do projeto no GitHub abaixo.

Projeto/Documentaзгo no Github
Downloads

GitHub

Crйditos
Mandrack_FreeZe pelo desenvolvimento do Plugin e include.

[RebeloX]

Nгo estб mau, contudo acho que as funзхes deviam ser todas em inglкs assim como as variбveis, seguindo a convenзгo normal que й transversal a qualquer linguagem de programaзгo. Isto й, criar variбveis em portuguкs й um grande nгo.

Acho que tambйm a modularidade em C++ deveria ser utilizada, por norma as classes ficam sempre definidas no .h (header) e a definiзгo interna dos mйtodos ficam definidas nos .cpp. Isto sгo tudo convenзхes e formas de organizar o cуdigo, em termos funcionais funcionarб da mesma forma.

Bom trabalho!

[Mandrack_FreeZe]

Quote:

Originally Posted by RebeloX Nгo estб mau, contudo acho que as funзхes deviam ser todas em inglкs assim como as variбveis, seguindo a convenзгo normal que й transversal a qualquer linguagem de programaзгo. Isto й, criar variбveis em portuguкs й um grande nгo. Acho que tambйm a modularidade em C++ deveria ser utilizada, por norma as classes ficam sempre definidas no .h (header) e a definiзгo interna dos mйtodos ficam definidas nos .cpp. Isto sгo tudo convenзхes e formas de organizar o cуdigo, em termos funcionais funcionarб da mesma forma. Bom trabalho!

Bom dia RebeloX,

Obrigado pelo comentбrio e pela crнtica porйm sobre essa questгo das variбveis e funзхes em inglкs eu devo discordar fortemente partindo do princнpio que o idioma utilizado para criar as variбveis e funзхes do projeto devem ser escolhidos conforme melhor se adapta ao programador (e escolhi o portuguкs por ele ser o que melhor se adapta a mim). Eu lancei uma versгo em inglкs da include na board gringa aqui.

Sobre a questгo da modularidade em C++ pode ser realmente que os padrхes de organizaзгo do projeto podem estar um pouco errados porйm como dito antes й o que melhor se adapta a mim.

Mais uma vez obrigado pelo comentбrio, caso surja alguma dъvida й sу comentar.

[rjjj]

Sobre as convenзхes do C++ aplicadas no cуdigo-fonte do plugin, penso que se pode sem problemas aplicar sua prуpria convenзгo de nomes (por exemplo, Pascal Case em nomes de classes e Snake Case em nomes de mйtodos). Й suficiente que o cуdigo seja inteligнvel para um ser humano comum e interessante que seja tambйm reutilizбvel (isto й, sem repetiзхes desnecessбrias) .



Sobre mуdulos em C e C++, simplesmente nгo existe um sistema de mуdulos apropriado nessas linguagens. Esperava-se que o C++ 11 fosse trazer isso como novidade, o que infelizmente nгo aconteceu.



Inspirada nas linguagens Fortran e BCPL, porйm, a linguagem C trouxe uma keyword denominada extern para se fazer divisгo de memуria por overlays, visto que a ocupaзгo de memуria computacional era preocupante naquele tempo. Esses segmentos de memуria sгo os arquivos objetos, processados pelo vinculador (linker) apуs toda a traduзгo do cуdigo-fonte pelo compilador (compiler) .



Nos dias de hoje, й quase uma obrigaзгo cultural entre os programadores de C e C++ fazer divisгo com arquivos .c/.cpp e .h/.hpp para cada mуdulo individual de um projeto, com a justificativa de separaзгo entre interfaces e definiзхes. No meu ponto de vista, й um absurdo, pelo fato de a "regra" ser quebrada pelas keywords inline e template, alйm do uso do extern do C ter se desviado do seu foco original.



Felizmente, contudo, a linguagem D superou essas prбticas atravйs de um verdadeiro sistema de modularizaзгo atravйs de arquivos .d .



Espero ter ajudado .