| Age | Commit message (Collapse) | Author |
|
run faster. This fixes ticket #235.
Incidentally, refactor exif and search to use the same patterns
overall so that if you understand one, you understand the other and
they generally use the same strings for localization.
|
|
|
|
|
|
have a single exif_record for each item instead of 1 per key. It's
about 5x faster to scan photos this way.
|
|
|
|
this is a great solution, but it'll probably cut down on a big class of errors opportunistically
|
|
|
|
- Add a "captured" column to the items table.
- Pull the DateTime EXIF field and put it into the captured column
- Pull the Caption EXIF & IPTC fields and put them into the description
field if there was not already a value there
|
|
appropriate. This allows us to switch the exif value column back to
varchar and improves the way that we deal with non-utf8 data in our
embedded EXIF/IPTC data.
|
|
|
|
many separate queries.
In the process, rip out the summary column, we weren't using it.
Clean up the test, and drop the exif_records database on uninstall.
|
|
|
|
* Create Exif_Record_Model to track whether we've scanned the EXIF
data for this photo or not. This allows us to track photos that
don't have EXIF data (and won't have any Exif_Keys)
* Blow away old Exif_Keys when extracting, else we hit unique
index constraints.
* exif::_get_stats() -- before it was running the task forever
|
|
Changed exif to EXIF in comments
|
|
|