Database I/O Manager (DbIo) Plugin [Support Thread]

[lat9]

Ah, bummer! Is it something I could update via sql command (and, if so, what would that command look like)? I basically want to reset the date added on all products to match the launch date of the site, when it's ready. Thanks!

To update all products' date-added to the current date:

UPDATE products SET products_date_added = now();

Note that the above query will work in your Zen Cart admin's Tools / Install SQL Patches and, if your DB_PREFIX is an empty string, in phpMyAdmin.

If you're running the query in phpMyAdmin and you use a DB_PREFIX (e.g. 'zen_'), you'd use

UPDATE zen_products SET products_date_added = now();

[mcqueeneycoins]

To update all products' date-added to the current date:

UPDATE products SET products_date_added = now();

Note that the above query will work in your Zen Cart admin's Tools / Install SQL Patches and, if your DB_PREFIX is an empty string, in phpMyAdmin.

If you're running the query in phpMyAdmin and you use a DB_PREFIX (e.g. 'zen_'), you'd use

UPDATE zen_products SET products_date_added = now();

Works perfectly--thank you as always lat9! Happy holidays!

[retched]

Is there a guide or a set of best practices for when it comes to creating your own handler for importing?

In my case, I created a set of product types that each reads from a different table. How would I direct DBIO to import data received under one handler and send it to the necessary table?

[lat9]

Is there a guide or a set of best practices for when it comes to creating your own handler for importing?

In my case, I created a set of product types that each reads from a different table. How would I direct DBIO to import data received under one handler and send it to the necessary table?

You'd set the single handler's setHandlerConfiguration method to identify all the potential, albeit product-type-specific, tables that could be used.

On an import, I'd suggest using the handler's importCheckKeyValue method to determine which 'type' of product is being imported for the current CSV record, saving that in a method-specific class parameter which is subsequently used by the handler's importProcessField. That method would interrogate the product-type being dealt with so that it's aware of which of the possibly multiple product fields are to be used.

[retched]

You'd set the single handler's setHandlerConfiguration method to identify all the potential, albeit product-type-specific, tables that could be used.

On an import, I'd suggest using the handler's importCheckKeyValue method to determine which 'type' of product is being imported for the current CSV record, saving that in a method-specific class parameter which is subsequently used by the handler's importProcessField. That method would interrogate the product-type being dealt with so that it's aware of which of the possibly multiple product fields are to be used.

So is there no need to make a separate handler for each additional type?

[lat9]

So is there no need to make a separate handler for each additional type?

It's up to you, but I think that you could do a single version that manipulates a product based on its product-type.

[retched]

It's up to you, but I think that you could do a single version that manipulates a product based on its product-type.

If fields are missing off the CSV import will they just be skipped and ignored?

[lat9]

If fields are missing off the CSV import will they just be skipped and ignored?

If, by "missing", you mean that the associated column is not present, the answer is "Yes".

If a column is present, but the value is an empty string, that value will be set for the 'row'.

[retched]

If, by "missing", you mean that the associated column is not present, the answer is "Yes".

If a column is present, but the value is an empty string, that value will be set for the 'row'.

Awesome. One final question, is there a way to get DBIO to work together with POSM as far as setting the stock levels of the attributes? I tried to read into the table created by POSM, and it's returning a hash field of some kind so I don't know how others managed to get it to work.

[lat9]

Awesome. One final question, is there a way to get DBIO to work together with POSM as far as setting the stock levels of the attributes? I tried to read into the table created by POSM, and it's returning a hash field of some kind so I don't know how others managed to get it to work.

For now, you'll need to 'purchase' the now-free version of POSM 5.0.0 (https://vinosdefrutastropicales.com/...products_id=46). That includes a set of DbIo handlers.

I'll be incorporating those, now that POSM's in-core, in a subsequent release of DbIo.