1 |
On Sunday, August 03, 2014 10:57:06 PM Alan McKinnon wrote: |
2 |
> On 03/08/2014 22:23, J. Roeleveld wrote: |
3 |
> > On Sunday, August 03, 2014 10:04:50 PM Alan McKinnon wrote: |
4 |
> >> On 03/08/2014 15:36, J. Roeleveld wrote: |
5 |
> >>>> Maybe this "protocol" is not the most clever solution, but it is |
6 |
> >>>> |
7 |
> >>>>> one which could be implemented without lots of overhead: |
8 |
> >>>>> Mainly, I was up to a "quick" solution which is working good enough |
9 |
> >>>>> for me: If the server has no bugs, why should it die? |
10 |
> >>>>> Moreover, if the server dies for some strange reasons, it is probably |
11 |
> >>>>> safer to re-queue the jobs again, anyway. |
12 |
> >>> |
13 |
> >>> With the kind of schedules I am working with (and I believe Alan will |
14 |
> >>> also |
15 |
> >>> end up with), restarting the whole process from the start can lead to |
16 |
> >>> issues. Finding out how far the process got before the service crashed |
17 |
> >>> can become rather complex. |
18 |
> >> |
19 |
> >> Yes, very much so. My first concern is the database cleanups - without |
20 |
> >> scheduler guarantees I'd need transactions in MySQL. |
21 |
> > |
22 |
> > Or you migrate to PostgreSQL, but that is OT :) |
23 |
> |
24 |
> Maybe, but also valid :-) |
25 |
> |
26 |
> I took one look at the schemas here and wondered "Why MySQL? This is |
27 |
> Postgres territory". It's a case of LAMP tunnel vision. |
28 |
|
29 |
That and that people who start with LAMP don't learn SQL. |
30 |
This leads to code that is near impossible to port to a different database and |
31 |
when people actually want to do all the work to get the SQL to work on any |
32 |
database, the projects involved refuse the patches. |
33 |
|
34 |
-- |
35 |
Joost |