-
Notifications
You must be signed in to change notification settings - Fork 1
Home
Please see blog page for news
Changes to database should be done so that updating the app keeps user's data unspoiled. Easier said than done, you'll have to: a) leave old fields unchanged b) add new fields to new tables c) or, implement database conversion. Read table in old format and write it back in new format. Once.
1.08 is a major change compared to 1.06 (The versions in Jolla Shop)
- more performance improvement
- Shop filtering (called earlier selection) is moved to a new page; there is a button on the first page.
- Corrected translations, hopefully improved
- Selection of multiple shops is supported
- Option storage is fully working
- Section division by item Class (iclass DB field), ordering and section heading display as options
- translations corrected, English, German (de), Spanish (es) remain non-native (my translation)
- I will leave database access and dbaccess.js with the present architecture for now.
This was not fully tested. The shop selection now allows selection of multiple shops to display. In order to allow for multiple shop selection, I had to work with the Sqlite3 interface. Someone wished that the list ordering could take in account the class of the item, and so it does; the class is a criterion for ordering, but the ordering isn't then fully obvious. They are ORDERed BY
- state ASCending
- class ASCscending
- internal sequence number DESCending (you have to see code to understand this)
- name ASCending
The query statement is assembled as a string.
The use of SectionHeaders is the way it was implemented in the list.
- Next release will come in june 2017
- Working on database CSV export and import. Quite lot of work, have to do part of it in Qt C++.
- There was a request for price counting / followup. Good idea, but it makes everything a bit more complicated.
- A wish for adoption of a certain internationalization service. Let's see...
- Simplicity / clutter tradeoff: simple app or all the features.
- The database boilerplate code in dbaccess.js is a bit dumb, I admit. Surefire yes, profiling showed that it's not propably the performance bottleneck, but GUI. One could optimize SQL access only to app startup and shutdown, or developing even smarter startegy. Prepared statements... At times I like to have both belt and suspenders, so Every Change Is a SQL access on the first version, thus application start/exit/crash data loading/storage strategy is not needed