Thank you Esteban & Joachim for your answers.
Laurent
Le lun. 18 sept. 2017 à 14:58, jtuc...@objektfabrik.de
<jtuc...@objektfabrik.de> a écrit :
Laurent,
I don't have answers to all your questions, but we use Glorp &
Seaside (no Magritte) on VA Smalltalk for our cloud service
(http://kontolino.de).
Am 18.09.17 um 12:22 schrieb laurent:
Hi all,
it's been a long time :) At work we are currently comparing several
technologies to start a business project that will hopefully be used
by thousands of people for several years ;)
We need a web stack and we put Pharo & co in the comparative
process. My team have strong experience in load-balanced php /
mysql deployment that handles millions of records but we are ready
to build on something else though MySQL is still a requirement.
Sounds interesting.
Thanks for Garage + Glorp, I can prototype things. I wonder how to
handle database schema migrations. With our PHP projects we have
versionned PHP scripts that are automatically run given a database
revision number ( see
http://git.afi-sa.fr/afi/opacce/tree/master/cosmogramme/sql/patch ).
What are the practices with Glorp ?
We use a similar approach: our Descriptor class has a method called
schemaVersion, which just returns the current version number. We also
have a "magic" table for settings in our DB, just holding a "name"
and a "value" column, both being Varchars. One of the rows has a name
of "SchemaVersion" and the value is (you guessed it) the printString
of the version number.
Our images accept a few command line paramters, one of them being
--upgradeSchema. It compoares the number in the DB with the one
provided by the descriptor. If they match, the image quits. If not,
it calls all methods named #upgradeSchemaToVersionXXX until it
reaches the number in the Descriptor. Thus we can do both SQL based
migrations, like DDL stuff, as well as Smalltalk object based
migrations (which can be sooo much faster to implement for complex
cases). And we have all versioned and maintained in our beloved Envy
repository ;-) .
The rest is just bash script magic (like only starting one image with
the --upgradeSchema parameter and only start the real web workers
once that one has ended succesfully).
About load balancing: You need Sticky sessions, so no failover
between images. If one image crashes, the user must re-logon on a new
image. Works nicely with Apache, I guess nginx works as least as
well. For Apache, look for mod_prox_balancer to learn more.
Hope I could give you a few starting points for your research. And I
also hope you'll find Pharo+Garage+Glorp+QCMagritte a good fit for
your project. We all want success stories ;-)
Joachim
--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel mailto:jtuc...@objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
D-71640 Ludwigsburg
http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
