Can we add the ability to have the architecture capability for a multiple database backend with a single code base frontend too? This will help with clients that do not want other clients hands in their cookie jars and allow us as developers to have a single code source to develop, update and maintain.
Can we add the ability to have the architecture capability for a multiple database backend with a single code base frontend too? This will help with clients that do not want other clients hands in their cookie jars and allow us as developers to have a single code source to develop, update and maintain.
not sure entity framework is optimized enough for other database backend. You think it can provide the jobs done ?
Can we add the ability to have the architecture capability for a multiple database backend with a single code base frontend too? This will help with clients that do not want other clients hands in their cookie jars and allow us as developers to have a single code source to develop, update and maintain.
not sure entity framework is optimized enough for other database backend. You think it can provide the jobs done ?
Yes, I do think that Entity Framework will work just fine. Each store can have its own connection string associated with it. Any functions/methods that require more overhead should be moved to a stored procedure on the database side if possible anyway.
4) True Product kits where a "parent" SKU is a combination of "child" SKUs, a "grandparent" SKU is a combination of parent and child SKUs, etc. and all respective Inventory stock levels are appropriately depleted. The existing Product Group isn't feasible because the Grouped Product can't be purchased. The hack using Product Attributes isn't feasible because the fudged components themselves can't have Product Attributes.
For example, a workstation grandparent SKU consists of a laptop (parent), docking station, monitor and external hard drive (child SKUs). The parent laptop SKU has different size CPUs, hard drives, RAM, etc. child SKUs We don't want a unique SKU for each size of memory, HDD, CPU, etc. - we want all their stock levels tracked by Attribute. Each component can be purchased separately.
Saving the language of the customer in a table so when you do marketing you can send email promotions in the customers language only using the userstate language isn't enough when doing marketing after the customer has left the site.
Saving the preferred language the customer speaks is a basic feature of any ERP or Ecommerce solution.
Belgium has 3 official languages Cyprus has 2 official languages Luxembourgh has 3 official languages Swiss has 4 official languages 1/3 of the USA speaks Spanish etc...
Saving the preferred language the customer speaks is a basic feature of any ERP or Ecommerce solution.
Can we add the ability to have the architecture capability for a multiple database backend with a single code base frontend too? This will help with clients that do not want other clients hands in their cookie jars and allow us as developers to have a single code source to develop, update and maintain.
not sure entity framework is optimized enough for other database backend. You think it can provide the jobs done ?
Yes, I do think that Entity Framework will work just fine. Each store can have its own connection string associated with it. Any functions/methods that require more overhead should be moved to a stored procedure on the database side if possible anyway.
oh I thought you meant to support multiple database plaforms like mysql, mongodb.... :D
automatic download digital product after purchase. remove required email filed for guest. and user can sign up and sign in with phone number instead of email.