awapi-local-db-sync - Project Hosting on Google Code

Last 7 days Dec 23, 2009 issue 3 (Migrate to API v2009) reported by martijnvermaat - At this point, the new API version v2009 does not include an equivalent of the v13 Report service. However, in a few months the v13 API will become obsolete and I assume there will be a v2009 equivalent of the Report service. Can we expect the AdWords API Local Database Sync project to be migrated to the v2009 API? At this point, the new API version v2009 does not include an equivalent of the v13 Report service. However, in a few months the v13 API will become obsolete and I assume there will be a v2009 equivalent of the Report service. Can we expect the AdWords API Local Database Sync project to be migrated to the v2009 API? Earlier this year Mar 10, 2009 awapi-local-db-sync-1.1.0.tar.gz (AdWords API Local Database Sync 1.1.0) file uploaded by api.jeffy - Labels: Featured Type-Archive OpSys-All Labels: Featured Type-Archive OpSys-All Mar 10, 2009 r3 (v1.1.0. Changed config to use v13, and general code cleanup....) committed by api.jeffy - v1.1.0. Changed config to use v13, and general code cleanup. v1.1.0. Changed config to use v13, and general code cleanup. Older Nov 19, 2008 issue 2 (SQL data type INT is not sufficient - to use at least BIGINT...) Status changed by api.jeffy - Yes, thanks for pointing this behavior out for non-SQLite databases. I'll change the CREATE statements in the next release. Status: Accepted Yes, thanks for pointing this behavior out for non-SQLite databases. I'll change the CREATE statements in the next release. Status: Accepted Nov 18, 2008 issue 2 (SQL data type INT is not sufficient - to use at least BIGINT...) reported by jyothirmayee - What steps will reproduce the problem? 1. Make changes to import into Mysql (or postgres) 2. Load db for an account with adgroup/keyword ids greater than the INT limit of MySQL/Postgres 3. Inconsistent data in the DB or import would complain of duplicates as numbers wrap. What is the expected output? What do you see instead? Exact ID value in the DB What version of the product are you using? On what operating system? 1.0.0 on Mac OSX Please provide any additional information below. Cause: Though sqlite limit for int is 8 bytes (same as bigint on other databases), it would help to change this to bigint for migration purposes or for extendibility. Solution: To be compliant across all databases Update "CREATE TABLE" SQL in config/production_config to use BIGINT UNSIGNED for all ID fields The largest value I have seen is 6025767243 which cannot be accommodated even in a INT UNSIGNED. The exact limit required is unknown and I think is not published anywhere on Google code. What steps will reproduce the problem? 1. Make changes to import into Mysql (or postgres) 2. Load db for an account with adgroup/keyword ids greater than the INT limit of MySQL/Postgres 3. Inconsistent data in the DB or import would complain of duplicates as numbers wrap. What is the expected output? What do you see instead? Exact ID value in the DB What version of the product are you using? On what operating system? 1.0.0 on Mac OSX Please provide any additional information below. Cause: Though sqlite limit for int is 8 bytes (same as bigint on other databases), it would help to change this to bigint for migration purposes or for extendibility. Solution: To be compliant across all databases Update "CREATE TABLE" SQL in config/production_config to use BIGINT UNSIGNED for all ID fields The largest value I have seen is 6025767243 which cannot be accommodated even in a INT UNSIGNED. The exact limit required is unknown and I think is not published anywhere on Google code. Nov 17, 2008 issue 1 (DB Import fails on large keyword sets ) changed by api.jeffy - Thanks for the suggestion. Switching over to ElementTree for the next release of the project sounds very reasonable. Status: Accepted Labels: Type-Enhancement −Type-Defect Thanks for the suggestion. Switching over to ElementTree for the next release of the project sounds very reasonable. Status: Accepted Labels: Type-Enhancement −Type-Defect Nov 17, 2008 issue 1 (DB Import fails on large keyword sets ) reported by jyothirmayee - What steps will reproduce the problem? 1. Configure for an import of an account with ~500K keywords (threshold not known) 2. Start the import 3. Tool hangs What is the expected output? What do you see instead? Expected:Import should be successful. After successfully downloading the report from google the tool hangs while parsing xml. High CPU and memory utilization. What version of the product are you using? On what operating system? version1.0.0, OS: Mac OSX 10.5 Please provide any additional information below. Solution: Seems like miniport xml parsing library was introduced to move away from PyXml which is abandoned. I am proposing we port this to ElementTree which is memory efficient and has decently good performance in terms of time taken. It also provides object oriented view of xml. Supporting article with benchmarks http://www.ibm.com/developerworks/xml/library/x- matters28/ In my case I had a keyword set of ~500K. The tool hanged for more than 2 hrs choking CPU and memory(>1GB). With the modification the memory never shot above 600M and import into db completed in less than 2 minutes. Patch file for update_db.py attached. What steps will reproduce the problem? 1. Configure for an import of an account with ~500K keywords (threshold not known) 2. Start the import 3. Tool hangs What is the expected output? What do you see instead? Expected:Import should be successful. After successfully downloading the report from google the tool hangs while parsing xml. High CPU and memory utilization. What version of the product are you using? On what operating system? version1.0.0, OS: Mac OSX 10.5 Please provide any additional information below. Solution: Seems like miniport xml parsing library was introduced to move away from PyXml which is abandoned. I am proposing we port this to ElementTree which is memory efficient and has decently good performance in terms of time taken. It also provides object oriented view of xml. Supporting article with benchmarks http://www.ibm.com/developerworks/xml/library/x- matters28/ In my case I had a keyword set of ~500K. The tool hanged for more than 2 hrs choking CPU and memory(>1GB). With the modification the memory never shot above 600M and import into db completed in less than 2 minutes. Patch file for update_db.py attached.

issue 1 (DB Import fails on large keyword sets ) reported by jyothirmayee - What steps will reproduce the problem? 1. Configure for an import of an account with ~500K keywords (threshold not known) 2. Start the import 3. Tool hangs What is the expected output? What do you see instead? Expected:Import should be successful. After successfully downloading the report from google the tool hangs while parsing xml. High CPU and memory utilization. What version of the product are you using? On what operating system? version1.0.0, OS: Mac OSX 10.5 Please provide any additional information below. Solution: Seems like miniport xml parsing library was introduced to move away from PyXml which is abandoned. I am proposing we port this to ElementTree which is memory efficient and has decently good performance in terms of time taken. It also provides object oriented view of xml. Supporting article with benchmarks http://www.ibm.com/developerworks/xml/library/x- matters28/ In my case I had a keyword set of ~500K. The tool hanged for more than 2 hrs choking CPU and memory(>1GB). With the modification the memory never shot above 600M and import into db completed in less than 2 minutes. Patch file for update_db.py attached.

What steps will reproduce the problem? 1. Configure for an import of an account with ~500K keywords (threshold not known) 2. Start the import 3. Tool hangs What is the expected output? What do you see instead? Expected:Import should be successful. After successfully downloading the report from google the tool hangs while parsing xml. High CPU and memory utilization. What version of the product are you using? On what operating system? version1.0.0, OS: Mac OSX 10.5 Please provide any additional information below. Solution: Seems like miniport xml parsing library was introduced to move away from PyXml which is abandoned. I am proposing we port this to ElementTree which is memory efficient and has decently good performance in terms of time taken. It also provides object oriented view of xml. Supporting article with benchmarks http://www.ibm.com/developerworks/xml/library/x- matters28/ In my case I had a keyword set of ~500K. The tool hanged for more than 2 hrs choking CPU and memory(>1GB). With the modification the memory never shot above 600M and import into db completed in less than 2 minutes. Patch file for update_db.py attached.

Last 7 days

Earlier this year

Older