Cambios en los datos de conexion a Sphinx

[Jorge T.M.]

Buenas a todos,

He hecho un par de modificaciones en las clases Sphinx y DebugSphinx para que los datos de conexión los coja del domains.config, así se pueden configurar entornos de desarrollo con distintos parámetros. En principio es retrocompatible, es decir, si no especificas los datos en el domains.config los cogerá del sphinx.config como hacía hasta ahora. En el debug podemos ver qué archivo ha utilizado.

Si tenéis algún problema en vuestros proyectos no dudéis en avisarme.

Saludos!

PD: Por alguna razón mis diffs salen como si cambiarse el archivo por completo, supongo que es algún tema de saltos de línea. Si algún artista puede iluminarme para resolver este problema se lo agradeceré eternamente.

[Sergio Ambel Santoyo]

En PHPStorm,

ve a Settings -> Code Style -> General -> y cambia la configuración de Line Separator de System Dependent a  Unix

a ver si así... ;)

-Sergio

2012/8/12 Jorge T.M. <the...@gmail.com>

[Jorge Tarrero]

Gracias artista

--
Jorge T.M.

[Albert Garcia]

Retomo este mail.

En relación a esto, lo último que hablamos no iba precisamente en sentido contrario, es decir, evitar llenar el domains.config de datos de conexión de Sphinx, Amazons, MySQL, etc. y usar archivos de configuración para eso? En todo caso, domains es el que dirá si la instancia es de desarollo o de producción, pero los datos de conexión deberían estar en un config de Sphinx (o MySQL, o whatever). ¿No os parece?

Salutti,
--
Albert García Gibert
email. albert...@gibert.es
blog. http://obokaman.com
twitter. @obokaman

[Jorge Tarrero]

Claro, y sigue siendo asi, lo que he añadido es la posibilidad de especificar los datos de conexión también en el domains para que sea más sencillo configurar los entornos de desarrollo. Luego te pongo un ejemplo, que ahora estoy en el móvil

Salutti con tomatti

[Jorge T.M.]

Supongamos que tenemos un dominio de producción, por ejemplo vinosyquesitos.com, definido en el domains.config en el cual NO especificamos la clave "sphinx". Es este caso el Search.php decide que tiene que coger los datos de conexión directamente del sphinx.config.php, lo que significa que los cambios que hice son retrocompatibles

Ahora supongamos que queremos un entorno de desarrollo en la misma máquina de antes, por ejemplo albertg.vinosyquesitos-dev.com, en el cual no queremos usar los datos de conexión de producción, sino tener un demonio distinto, con otros indices y puerto. Los cambios permiten definir todos estos parámetros en el domains.config, de tal forma que sólo aplican a tu entorno de desarrollo. En forma de código:

$config['albertg.vinosyquesitos-dev.com']['sphinx'] = array(

'active' => true,

'server' => 'localhost',

'port' => 9310

);

$config['pablor.vinosyquesitos-dev.com']['sphinx'] = array(

'active' => true,

'server' => 'localhost',

'port' => 9311

);

Como ves ahora Pablo tiene un puerto de conexión a sphinx distinto al tuyo, con lo que podéis levantar dos demonios distintos para desarrollo, así no os pisáis.

La otra opción es coger y definir los dominios directamente en el sphinx.config, pero esta forma me parecía más limpia y se duplica menos código.

Para cualquier duda estoy a vuestra disposición

Saludos!

[Albert Garcia]

Buenas!

Por un lado el uso que comentas me parece muy muy arriesgado, no? En mi opinión es abrir la puerta totalmente a lo típico de "vaya, pues en mi working copy funcionaba". No acabo de entender esto de necesitar múltiples entornos de desarrollo. Como mucho, si alguien está trabajando sobre una versión específica del índice y necesita levantar un demonio aparte, lo más lógico es que lo modifique temporalmente, en su WC local y como mucho lo mantenga en un stash, pero que cada uno lo tenga diferenciado y versionar esas diferencias... Fiu... pero vamos, my biased opinion.

Por otro lado, incluso aunque hubiera esa necesidad, no te parece que sería más limpio tener un sphinx.config (reemplácese Sphinx por cualquier servicio externo, MySQL, Redis, Amazon, Mail, etc.) con los perfiles de conexión que tiene la instancia, y que como mucho en el domains se especifique qué perfil usa cada dominio? Si acabamos metiendo TODOS los datos de conexión de Sphinx en el domains... no habría argumento alguno para no acabar metiendo los de MySQL, los del mail, cache, etc. imagínate qué panorama. 

Kisses,

--
Albert García Gibert
email. albert...@gibert.es
blog. http://obokaman.com
twitter. @obokaman

[Albert Lombarte]

Hola,

Varias cosas.

En primer lugar sí es necesario tener la posibilidad de definir distintos entornos de desarrollo y poder tener la libertad de hacer commit sin tener que acordarse de volver a dejar los parámetros de conexión como estaban (eso sí es peligroso).

Sobre si se mete en domains o no, actualmente domains.config.php soporta los siguientes parámetros de configuración NO RELACIONADOS con el dominio (sino con el entorno, y que por tanto son susceptibles de ir en otro lado):

• media_host (este de hecho se tendría que quitar por defecto y añadirlo específicamente en los proyectos que lo usen)
• database (mysql pdo o ADODb con los mil drivers)
• redis
• sphinx (de la mano de Jorge)

En su día cree la entrada libraries_profile que aunque no se utiliza demasiado, permite, por dominio, decir que librerías se utilizan bajo un nombre (ej: bleeding_edge, default, etc...). Este conjunto de librerías se recopilan en libraries.config.php. Es el lugar donde podemos cambiar la versión de Smarty a una RC en desarrollo por ejemplo y dejar en producción una estable.

Similarmente debería aplicarse este sistema o uno parecido para todos los perfiles de conexión, incluido Mysql. Criticar que estamos metiendo Sphinx en domains y luego tener Redis y Mysql ahí... pues hombre, no habría diferencia.

Me parece bien modificar las librerías para segmentarlo todo y que sea cada fichero (mysql.config.php, redis.config.php, sphinx.config.php...) el que acabe definiendo sus distintos perfiles de conexión soportados y que simplemente sea Domains el que diga qué perfil se va a cargar de todos ellos. Mirad que libraries.config.php sólo define en los perfiles distintos de default los cambios.

Esto es un major change en el que todo el mundo debe arremangarse.

2012/8/20 Albert Garcia <albert...@gibert.es>

[Albert Garcia Gibert]

En realidad criticaba tenerlo todo (también MySQL o Redis) en domains.config, la cosa no iba por Sphinx sólamente. :-)

Actualmente Sifo ya permite definir un nombre de perfil (PRODUCTiON, DEVELOPMENT, etc.) y tener los datos de conexión de MySQL en un fichero de config aparte, para no meterlo en domains. Lo que decía precisamente era hacerlo todo así. 

Kisses,

El 20/08/2012, a les 15:40, Albert Lombarte <alom...@gmail.com> va escriure:

[Albert Lombarte]

https://github.com/alombarte/SIFO/issues/14

2012/8/20 Albert Garcia Gibert <obok...@gmail.com>

[Jorge Tarrero]

Entiendo que los cambios que subí son validos por ahora. Empezaré a investigar alguna forma decente de sacar toda la morralla del domains.config y hacer estas personalizaciones por perfiles que comentáis.

Saludos!

--
Jorge T.M.

[Albert Lombarte]

Hola,

Si nadie dice lo contrario, si los cambios son retrocompatibles y no afectan al funcionamiento de nada, haría el merge a master.

Espera un poco por si Pablo/García/Sergi tienen algun inconveniente y si no nos llevamos los cambios de Sphinx y GENURL.

Gracias

2012/8/20 Jorge Tarrero <the...@gmail.com>

[Albert Garcia]

Dadnos un par de días para probar en desarrollo, please. 

Thx!

--
Albert García Gibert
email. albert...@gibert.es
blog. http://obokaman.com
twitter. @obokaman