Faster or not?

[whiskyjohn]

There isn't a method to purge a single hand - the smallest purgeable item is a session. You could identify sessions containing those hands and then purge those sessions via Database Management -> Purge Hands and reimport the hands at that point. It really depends how common it is whether that's feasible or not.

kraada, you are being obtuse. I don't want to purge anything!

Imagine Pokertracker X.Y.Z released a bug fix with the description:
"Fixes hands."

It is not important what is fixed or how many hands are fixed. They are fixed.
Now, what about hands already in the database? How do I fix them without rebuilding the database from scratch?

The obvious solution is to reimport all hands. But just what this does is perhaps a bit tricky. Again, my knowledge
of Postgresql/PT internals is short. Are all database records keyed off a unique hand number? If so, I can imagine
a record checksum. When a hand is imported, first an import checksum is produced. If the import checksum matches
the record checksum, then it is truly a duplicate hand and nothing needs to change. If they differ, then fields
are changed accordingly.

But the above assumes changes to a record are autonomous and do not affect other records. If that is not the case,
then there must be some design mechanism that touches all records that need to change.

Now it could be that the "Fixes hands" fix is so extensive that it is simply faster to rebuild the database from
scratch. But under no circumstances should it be impossible to reimport all hands and NOT fix the database!
Furthermore, It should *never* be required that the user identify hands or sessions or whatever to purge and
then go through all that mess.

So again I ask, how do I "fix" my database when PT comes out with fixes? Apparently, I don't, unless I am
prepared to build the whole thing from scratch again.

John

[BillGatesIII]

I have never understood why hands have to be re-imported if there is a change in a field definition because the original hand histories are in the database (tables cash_hand_histories and tourney_hand_histories). And most of the time you don't need the original hand histories because it's possible with a script to update the databasefields which are affected.

[whiskyjohn]

I have never understood why hands have to be re-imported if there is a change in a field definition because the original hand histories are in the database (tables cash_hand_histories and tourney_hand_histories). And most of the time you don't need the original hand histories because it's possible with a script to update the databasefields which are affected.

Good point.

Though in order to apply such a patch, one would need to write a unique patch applicator for each bug fix that updated only those database fields
affected. Though, there is a way to automate this process also. But you can think about the hand importer as the ultimate patch applicator as it does
everything necessary to "fix" all database fields without any knowledge of what fields are affected.

However, after offending fields are updated, I am fuzzy on what needs to happen after that.

I'm not looking to reinvent the wheel here. I just want some efficient means of fixing existing hands in my database that doesn't require rebuilding
the entire database!

John

[kraada]

I wasn't trying to be intentionally obtuse I was trying to give you a way that will work with what we have.

[whiskyjohn]

I wasn't trying to be intentionally obtuse I was trying to give you a way that will work with what we have.

Fair enough. But on a large database, even if I did know what to purge, this action, followed by reimporting, followed by rebuilding,
is just going to take a ridiculous amount of time.

There really needs to be a way to "fix" the database fields affected by a new release. How can this software be so mature and yet
so bassackwards at the same time?

John