Implemented How ochsubscriptions_orders table is cleaning?

Hi Ruud,
I go to phpmyadmin and investigate what's happening there.
ochsubscriptions_orders has approx. 34 000 entries.



The same amount is in RDSubs table. So, when we migrated, all the data from this table were moved.
The question is: which data are purged via cron on OchSubs side?
I see this one:

• Purge Unfinished Orders
• Purge Temporary Transactions

Is it works for recent orders/transactions only? We need your advice. Should we just purge  ochsubscriptions_orders table?

Thank you.

Regards,
Eugene
 

#__ochsubscriptions_temp_transaction is purged when configured to do so. It deletes all records older (based on created field) then the configured number of days.

#__ochsubscriptions_orders is purged when configured to do so. It deletes all records older (based on created field) then the configured number of days where there is NO CORRESPONDING record (linked via ordercode) in the #__ochsubscriptions_transactions table

Is it a daily cron job?

Yes,

the log file should have the count for the number of entries cleaned / removed

Hmm, daily cron job shows 0 Unfinished orders removed.
That is strange as we do have much LESS then 34k records in transactions table.

so currently all record in orders table have a corresponding record in transaction table, only the order that do not have a record in transactions table are removed.

We have much LESS then 34k records in transactions table. So something is not right here.
Records table - 34K. Transactions table - much less then 34K.

can you provide me a (sql) dump of both tables?

Sorry I can't, but this query gives 818 records for me:

SELECT o.id FROM `#_ochsubscriptions_orders` o
LEFT JOIN `#_ochsubscriptions_transactions` t ON t.ordercode = o.ordercode
WHERE o.ordercode = t.ordercode;

And ochsubscriptions_transactions has 34 749 records.

Okay so debugged this with my own tables. As it turns out, the query used is returning unexpected results when using the Joomla db loadassoclist method when a value is NULL.

I am not going to dig deeper into why this is happening, this can be related to database version or the way J4 handles NULL values in tables. It is very likely that this also didn't work in rd-subs as that was using the same logic.

In new dev version I worked around the issue by using a different db load method.

On my test setup it works.