Mysql Cluster support

[Fivell]

In MySQL Cluster auto_increment values are stored in the distributed database
since they are global (per table). Since it is much more expensive to manage such
counters than in a local non-distributed database, the auto_increment values are
pre-fetched in batches (currently of size 32).

so running two clients, where inseringt in the first I get 0 (since it has a batch 0 - 31) and inserting in the
second I get 32 (since it has a batch of 32-63).

So scopes of version class where primary_key is used are not working with Mysql Cluster

[airblade]

What would you suggest? I don't have any experience with MySQL cluster and I'm not sure how to work with database records if you can't use primary keys.

[Fivell]

I suggest not to use primary key for logic that determine order(sequence) of rows
for example "next" method can use created_at but not primary key
or it can be optional with opportunity to use created_at instead of primary key

[airblade]

Thanks for the clarification. Please feel free to send me a pull request.

[Fivell]

now I have doubts about using created_at for determine sequence, because in some custom logic version records with same itemid can be created at the same time (create and update in the same time) so even using created_at wouldn't guarantee right order. I think it would be better to add additional column to store time with microsecond , and create monkey patch for using this column in needed methods

[batter]

This issue should technically be solved now I think, in the sense that I've mostly removed the usage of the primary key for logic to determine order of rows. See 6a4aba2. This was done in order to stay in line with the modifications that were made for #235. Seems like this issue is closely tied to the same problems in #131, but at least PaperTrail should now work out of the box with MySQL cluster (albeit perhaps not perfectly depending on how the sequence of create and update statements work in that setup).

[jaredbeck]

This issue should technically be solved now I think, in the sense that I've mostly removed the usage of the primary key for logic to determine order of rows.

@Fivell Given Ben's comment (above) from 2013, it sounds like this is fixed (assuming you can synchronize the system clocks across your cluster :) ). If so, can you close this issue? Thanks.

[Fivell]

Sure.