I have written an extension for Virtuemart 1.1.9 which retrieves products from the virtuemart database. This primarily uses the '#__vm_product" table.
Now that I have started to write a Virtuemart 2.x compatible version I have some questions.
I have noticed that my product table containing the product names is in "#__virtuemart_producs_en_gb"
I am assuming that virtuemart has detected my language during install, and created these tables with the "en_gb" suffix automatically.
My questions are:
What is the best way to detect what the suffix is likely to be on these product tables, as I am assuming that the suffix could be anything in theory, "en_us" for example, or "fr"?
Is there a config value I can search for which contains this language setting?
Any ideas about the best way to tackle this issue?
Regards
James
Actually, this may be a way of doing it...
$query="SELECT lang_code FROM #__languages";
$db->setQuery($query);
$lang_code = $db->loadResult();
$lang_code = strtolower(strtr($lang_code,'-','_'));
//this will fetch "EN-GB" from the database, and change it to "en_gb"
any thoughts on its reliability?
Related
I wanna know if Django has any module to deal with this problem.
I have multiple ways of writing the same city name in a Postgresql database that came from scraping different websites. The field "city name" could be "S. Diego" or "San Diego". My question is if I could have a module that could normalize always to "San Diego" in both situations and I could add some normalization when some new word appear like "S Diego", and maintain this workflow.
Thanks
You can use an API to normalize the data you have scraped. Yandex or Google have feature to return a possible list of the location names based on your search query. Get the most possible answer they returned and use it to map your input to the correct one. There are manual mapping features but I highly recommend one of the giants that solved the problem before us.
Is there a way to set our own index name in Django models? Currently, the migration scripts would create a name in format [table_name]_9fcb4ba3 and I'd like to have the name more descriptive, i.e. [table_name]_[column_name] or so.
On the Django's Model Field Reference page, it doesn't seem to have such option (https://docs.djangoproject.com/en/1.8/ref/models/fields/#db-index)
For anyone finding its way from Google - seems Django 1.11 allows you now to have a custom name for indexes. Following the documentation as described here:
Index.name
The name of the index. If name isn’t provided Django will auto-generate a name. For compatibility with different databases, index names cannot be longer than 30 characters and shouldn’t start with a number (0-9) or underscore (_).
There is no way of customizing the name for indexes as these are generated by hashing (the index name calculation uses some hashing techniques)
I would like to use the cloning feature of Sitecore to create sites with similar content to different countries. Mostly, it would be useful if changes to master site (Russian) would be automatically reflected on the sub-sites.
The first problem I have is that I seem to get language versions of all the items (German, English), not just Russian, when I create the clone
The second problem is that the clone does not have items in the targets I want, e.g. Belorussian, so do I have to create it manually?
This seems like the kind of situation where cloning would be useful, but I am wondering if Sitecore architecture prevents me from actually using it?
We have the same architecture you described for almost every of our sites. We have a "Master"-site with all overall content. This site has no <site>-configuration. For every country site we create a clone of this content tree and add a corresponding <site>-configuration. Of course we add there some country-specific content:
Master
- Home
- Sitemap
- Error
- ...
Germany [Clone]
- Home [Clone]
- Sitemap [Clone]
- Error [Clone]
- Our Office
- ...
USA [Clone]
- Home [Clone]
- Sitemap [Clone]
- Error [Clone]
- Differences
- ...
This works fine, but has two drawbacks (as you also mentioned):
The items in the master have to have a version in each language available in any of the country sites (so yes, the author may have to create the language version in the master-site and clone the item afterwards)
The clones then have a version in each language, also if the language is not used in the country site
For the second point we've added a new parameter to the <site>-configurion called "availableLanguages". If the user requested i.e. an item in the "Russian"-language on "USA" (which is not available), we show a 404 error to the user. We make this possible by using the Sitecore Error Manager module, which also covers this parameter.
As said before we use this in almost every website we have and it works very well. It's also easy to understand for the authors.
I have a C++ application that stores data in a database (SQLite) through QxOrm.
It is clear that in the next versions, columns are gonna be added/removed/renamed, so I would like to set a version number to each database created, so that when someone tries to load a database it compares its version with the current version of the application and automatically add/remove/rename the columns to match the current schema.
I couldn't find in the QxOrm documentation something that would look like:
qx::QxSqlDatabase::getSingleton()->setVersion(2);
So first is it possible to do that kind of thing with SQLite? and if not should I just create a table that would hold the database version?
A database version is perhaps not enough : you should store a version per persistent class (and maybe other informations per persistent class, like list of columns for example).
When you register a persistent class into QxOrm context, you have to put a version number :
QX_REGISTER_HPP_XXX(myClass, myBaseClass, myClassVersion)
You can find some informations about creating a SQL schema into the FAQ of QxOrm library :
http://www.qxorm.com/qxorm_en/faq.html#faq_230
Using introspection engine of QxOrm library, it's quite easy to do, more details about introspection engine here :
http://www.qxorm.com/qxorm_en/faq.html#faq_190
You should create a table into your database to store a state for each persistents classes : you can store a version number per class, a list of columns, etc... Then it will be quite easy to compare 2 versions of persistent class to modify your SQL schema.
Now, you have QxEntityEditor application to manage your database schema evolution.
QxEntityEditor is a multi-platform and cross-database graphic editor for QxOrm library.
A video presentation of QxEntityEditor features is available here : http://www.qxorm.com/qxorm_en/tutorial_4.html
I am using the API V2 "salesOrderList" for receiving a list of all the Orders which have been placed in Magento. But the SOAP Response is showing me an error as:-
Item (Mage_Sales_Model_Order) with the same id "1" already exist
I am using the Magento Enterprise version 1.9.0.0.
After looking into the SQL & searching the database, I found that for each Order, the SQL is providing 4 records for the same Order Entity ID; with the difference being only in the name fields of the billing & shipping area. Also the query is doing two Left Joins with the same database table "sales_flat_order_address" by using two different aliases (one for billing & another for shipping). From my understanding, this should have worked, which is not happening.
Can anyone please suggest as to what is happening & what can be done to recover from this error?
Any help is appreciated and thanks in advance.
Roughly, Magento is creating an order collection for you and attempting to load all the records. This collection has a rule that only allows it to create one order object for each ID, so when your additional object is loaded an exception is thrown.
The left joins could be the issue, but it's hard to say off the bat. Could you post a little detail on how you are making the API call? An incorrect join can often have this problem.
EDIT:
If you're using the default code, my first guess would be that there are erroneous records in the database, or that this is an upgraded Magento system which had a bad upgrade in the past. Try this on a clean copy of your EE version pointing to the same database. If the same problem occurs, you may need to spelunk in the database looking for the reason for the problematic data load. Since you already have the query, you may want to separate out parts of the query to see if some subquery is returning too much data.