Decide which fields to export/ignore

[sneakypete81]

The export script currently only exports the following fields:

EXPORT_FIELDS = ["dateTaken",
             "dateUploaded",
             "description",
             "filenameOriginal",
             "latitude",
             "longitude",
             "license",
             "permission",
             "rotation",
             "status",
             "tags",
             "timestamp",
             "title",
             "views",
             ]

I've done this because I wasn't too sure which of the fields were safe to export - some clearly aren't (eg. id, pathOrigianal, etc).

Rather than maintaining a whitelist like this, it would be much better to just blacklist the fields that need to be ignored and export everything else.

@jmathai: could you please let me know which fields should be ignored?

[jmathai]

I think the whitelist is a safer approach actually.

Discuss......

On Sunday, January 26, 2014, sneakypete81 notifications@github.com wrote:

The export script currently only exports the following fields:

EXPORT_FIELDS = ["dateTaken",
"dateUploaded",
"description",
"filenameOriginal",
"latitude",
"longitude",
"license",
"permission",
"rotation",
"status",
"tags",
"timestamp",
"title",
"views",
]

I've done this because I wasn't too sure which of the fields were safe to
export - some clearly aren't (eg. id, pathOrigianal, etc).

Rather than maintaining a whitelist like this, it would be much better to
just blacklist the fields that need to be ignored and export everything
else.

@jmathai https://github.com/jmathai: could you please let me know which
fields should be ignored?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/2
.

-- Snet form my mobl phoone

[sneakypete81]

Perhaps - it certainly is safer. I was a bit worried that fields would get forgotten about, particularly when new fields get added to the DB in the future. But maybe this is a minor inconvenience compared with the dangers of accidentally exporting an "unsafe" field.

So alternatively, could you provide a comprehensive list of fields to whitelist?

[jmathai]

Based off the photo object...

    id, Base 36 value of a base 10 auto-incremented value
    appId, A string identifing the application creating this entry
    title, A title for the photo up to 100 chars
    description, A description for the photo up to 255 chars
    *hash, The sha1 hash of the original photo
    tags, A set of tags which is searchable inclusive or exclusively
    *rotation, Degress the user has rotated the photo (0, 90, 180, 270)
    *views, Number of times the photo was viewed (excludes views by the owner)
    permission, binary representation of photo permission (0=not public, 1=public)
    license, Abbreviation of the CC licenses such as BY, BY-SA, BY-ND, blank (All rights reserved) or free form (http://creativecommons.org/licenses/)
    dateTaken, Unix timestamp of when the photo was taken
    dateUploaded, Unix timestamp of when the photo was uploaded

• hash wouldn't be used but could be useful for various reasons
• rotation is not handled in the import script and I don't believe the upload API takes a rotation attribute (though that's a decent enhancement if anyone wanted to open an issue.
• views is not used at all and I don't think the upload API would ever support it --- but it might be data (once supported) that people want to keep.

In making this list I realized that this isn't a "replication" script as much as it is a script to move the more important (as defined by who?) pieces to a new instance.

[sneakypete81]

That looks like a good list to be getting on with.
I'm assuming that "id" shouldn't be included, however... Or will the upload API just ignore it?

[sneakypete81]

@jmathai: Is there any reason why we shouldn't include the following too?

filenameOriginal
latitude
longitude
status
timestamp

[jmathai]

@sneakypete81 We should be using filenameOriginal, latitude and longitude. I missed those.
timestamp is only used internally as is status.