...or maybe it is still all on the back of a fag packet for now....
Patience is a virtue and in this case I reckon 1.5.0 is well worth waiting for.
Well done Daniel and others for all your hard work.
robster
Patience is a virtue and in this case I reckon 1.5.0 is well worth waiting for.
Well done Daniel and others for all your hard work.
robster
I know my place...!
Thanks for the easy to understand explanationQphoria wrote:The extension table is only to determine which modules get loaded. All the settings are loaded from the setting table. So there is only 2 queries. The index loads ALL settings from the setting table to the config object. This is the biggest call of ALL settings and its one of the first things called.
The extension table is only called then to get a list of modules that are installed. So it is called once from column left, column right, and home for the type of extension of "module". Then grabs the data for each of those from the previously queried data that the config object now holds.
UGH! I didn't say which db data I had listed.
This is from my settings table:
Code: Select all
(1493, 'mymodule', 'mymodule_code1', '<p>\r\n this is the my module mod</p>\r\n')I do realize that is from a 3rd part mod and you get what you do for free but I think that more of this type of situation is going to happen once oc becomes more widely used.
Which is why I'm suggesting that things like this should get sorted sooner rather than later.
930sc ... because it is fun!
do you know of some other way to store html data in a database?SapporoGuy wrote:Qphoria wrote: So, I'm pulling up a text value in the db for a extra box to add on my page.
OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter
So you're saying that, with the settings table which uses a text field could store, 2,147,483,647 characters worth of :Xsecrets wrote:do you know of some other way to store html data in a database?SapporoGuy wrote:Qphoria wrote: So, I'm pulling up a text value in the db for a extra box to add on my page.
should be stored in the settings table?Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat laboris nisi ut aliquip.
I'm not just talking about any table, but the settings table.
930sc ... because it is fun!
No, that much html shouldn't be stored in the settings table and a module that requires that sort of storage should create it's own storage tables and use the settings table to link to the content.
http://www.alreadymade.com
Follow me on twitter.com/alreadymade
I have been too tied up to follow Opencart for the past week or so but I now have a back-office running.
I would be very interested to know what database changes there will be in 1.5.0. Is there a provision list of table changes available?
I would be very interested to know what database changes there will be in 1.5.0. Is there a provision list of table changes available?
Free v1.4.9 Extensions: Default Specials | Improved Search | Customer Activity Report | Customer Groups | Royal Mail With Handling | Improved Product Page | Random Products | Stock Report | All Products
come on you've been around here a while. You know they never give us any of that type of information until after they release and all the users are having problems and asking questions.mystifier wrote:I have been too tied up to follow Opencart for the past week or so but I now have a back-office running.
I would be very interested to know what database changes there will be in 1.5.0. Is there a provision list of table changes available?
OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter
I know, but I can't resist asking Daniel any more than I could resist tapping a sleeping snake with a stick.Xsecrets wrote:You've been around here a while. You know they never give us any of that type of information.
Free v1.4.9 Extensions: Default Specials | Improved Search | Customer Activity Report | Customer Groups | Royal Mail With Handling | Improved Product Page | Random Products | Stock Report | All Products
ZING!Xsecrets wrote:come on you've been around here a while. You know they never give us any of that type of information until after they release and all the users are having problems and asking questions.mystifier wrote:I have been too tied up to follow Opencart for the past week or so but I now have a back-office running.
I would be very interested to know what database changes there will be in 1.5.0. Is there a provision list of table changes available?
I'll be honest with you actually.. Upgrades from 1.4.x to 1.5.0 will be slightly screwed because of the product options change.
Options are now global, which means instead of there being an "product_option" table and "order_option" table
There is going to be a "product_to_option" table and an option_to_option_value table.
Options will no longer map to an individual product, instead they will only link by id in a pool. So I'm trying to figure a way to take the individual product options and merge them into the global options design.. and me thinks it will be impossible. But the global options will be much better in the long run in many opinions... so it might be something we have to live with. So upgrades from 1.4.x to 1.5.0 will likely blow away all product options.
Aside from that, there are new tables for attributes that won't break anything. There are reward points for products and categories which won't break anything.
But what's really cool is the new layout system daniel is working on. It will change templates as well so all templates will need to be started fresh, but if he can get it working the way he wants it will be revolutionary. This, however, will possibly delay 1.5.0 a bit longer while it gets fine tuned. But I think it will be worth it.
I suppose the only way to upgrade successfully the options to the new scheme is to take each option from a product and create a new option based on that, and save....will mean all the options are in the new global options then...it sucks if you have a lot of duplicate options, but will mean they don't get lost at least
The main problem with product options as they stand is that you might have:
Product: T-Shirt (10 in stock)
Colour: Red (4 in stock)
Colour: Green (3 in stock)
Colour: Blue (3 in stock)
Size: Small (2 in stock)
Size: Medium (5 in stock)
Size: Large (3 in stock)
If someone purchases a Medium Green T-Shirt, all three numbers decriment correctly but it is impossible to tell how many large blue ones are in stock because there is nothing to relate options.
Does the new schema address this? It is a reporting nightmare.
Product: T-Shirt (10 in stock)
Colour: Red (4 in stock)
Colour: Green (3 in stock)
Colour: Blue (3 in stock)
Size: Small (2 in stock)
Size: Medium (5 in stock)
Size: Large (3 in stock)
If someone purchases a Medium Green T-Shirt, all three numbers decriment correctly but it is impossible to tell how many large blue ones are in stock because there is nothing to relate options.
Does the new schema address this? It is a reporting nightmare.
Free v1.4.9 Extensions: Default Specials | Improved Search | Customer Activity Report | Customer Groups | Royal Mail With Handling | Improved Product Page | Random Products | Stock Report | All Products
Not yet. There are still no dependent options yet.. The issue with that is linking them all together. Typically you see the old car model example
Field 1: Make
Field 2: Model
Field 3: Parts
But that is very limited to only 3. Basically for each level you need another table.
So we need to figure a way to make an option_to_option field with a parent id that can be used for this.
But this comes down to how you list them as well. There is no reason you can't set them all as individual options.
Black/Large (2)
Black/Med (3)
Black/Sm (4)
Red/Large (3)
Red/Med (1)
Red/Sm (5)
I know magento has this:
http://demo.magentocommerce.com/zolof-t ... irt-1.html
But they have 50 people on the payroll
Field 1: Make
Field 2: Model
Field 3: Parts
But that is very limited to only 3. Basically for each level you need another table.
So we need to figure a way to make an option_to_option field with a parent id that can be used for this.
But this comes down to how you list them as well. There is no reason you can't set them all as individual options.
Black/Large (2)
Black/Med (3)
Black/Sm (4)
Red/Large (3)
Red/Med (1)
Red/Sm (5)
I know magento has this:
http://demo.magentocommerce.com/zolof-t ... irt-1.html
But they have 50 people on the payroll
Hah, actually looking at the source code for that magento example, its all bullsh!t. They just disable the second select box, but if you look at the source, the values are already set. They just make it look like its dependent. There is no ajax live headers being sent to a callback for this. So there is no dependent option there
When I was using Drupal's "UberCart" mod, the way they did it with stock control was they allowed you to create the product options, then when saved and edited again, there would be a new pane with every combination of the options, along with things like stock, sku, price etc. it's not an ideal way to do it, but it works
yeah dependant options and option combinations are a real pain. I haven't seen a system that does them really well. As far as entering the stock I really like the way the qtpro mod did it on oscommerce, but lets not even start talking about the oscommerce attributes it's probably one of the worst systems out there.
OpenCart commercial mods and development http://spotonsolutions.net
Layered Navigation
Shipment Tracking
Vehicle Year/Make/Model Filter
My initial approach would be to have a table with product_id, option_id, option_value_id and stock that contained every product, option and value combination.
This would allow queries such as:
Update pov set stock = stock - 1 where (product_id = [$pid]) and (option_id = [$oid]) and option_value_id = [$vid])
to decrement stock.
and:
select stock from pov where (product_id = [$pid]) and (option_id = [$oid]) and option_value_id = [$vid])
to check stock.
This would allow queries such as:
Update pov set stock = stock - 1 where (product_id = [$pid]) and (option_id = [$oid]) and option_value_id = [$vid])
to decrement stock.
and:
select stock from pov where (product_id = [$pid]) and (option_id = [$oid]) and option_value_id = [$vid])
to check stock.
Free v1.4.9 Extensions: Default Specials | Improved Search | Customer Activity Report | Customer Groups | Royal Mail With Handling | Improved Product Page | Random Products | Stock Report | All Products
Who is online
Users browsing this forum: No registered users and 22 guests
