sciencehistory / kithe Goto Github PK

Right now it doesn't, so you need to explicitly put to_a into your obj_extract paths, to turn it into an array.

One way to accomplish this would be to treat anything that respond_to?(:to_ary) as an array, rather than hard-coding ActiveRecord::Associations::CollectionProxy. Note that's to_ary not to_a, and thus should work fine, only things that really are meant to be interchangeable with Array should have to_ary.

I think this is a definite improvement... but ti's a backward incompatibility, since anything doing an explicit to_a will break.

Could be done with an obj_extract2 or something to be backwards compat. I dunno.

The main thing Kithe 2.0 will do is upgrade to using and requiring shrine 3.x.

That alone is probably enough to justify major version bump, since shrine is so fundamental to file handling, and apps are encouraged to interact with shrine directly.

But we will also take advantage of the major version release to change a few other things, primarily related to file-handling. The biggest fundamental (still tentatively planned) change will be replacing our custom derivatives handling code with the new shrine 3.0 derivatives code.

2.0 alpha release

We will release a 2.0.0.alpha1 (and possibly subsequent alphas) that uses shrine 3.x, but otherwise has as few changes as possible.

Apps are encouraged to use this as a stepping stone, and new apps created from kithe may want to use this version to start on shrine 3.

We will keep this work in a v3.0-alpha branch, and keep master on kithe 1.x until a later point. (Is this a good idea? Should we do vice versa and keep master with the latest work, and a 1-0-maintenance branch? I think not, for now).

2.0.0 final release

Most/all changes still related to file-attachment handling, and how we interact with Shrine. One goal is to let developers using kithe interact with Shrine more directly, using more standard Shrine functionality.

Work will be done on v3.0-progress branch, which includes all changes from v3.0-alpha (any changes to master should be merged to v3.0-alpha, and then v3.0-alpha merged to v3.0-progress)

Will include more changes, to be PR'd to v3.0-progress branch.

• Rework Asset promotion directives to be a bit more consistent, with more tests
• All custom logic in AssetUploader should be extracted to shrine plugins, it has nothing but plugins in it.
• Local apps should (optionally?) have a shrine uploader (normally AssetUploader class) locally, to do normal shrine customization
• before/after promotion hooks moved to the uploader, not the model? Now that local app can easily customize uploader.
• Replace custom derivatives implementation with shrine's new derivatives plugin
  • verify concurency-safety
  • migration code for going in both directions -- storage locations can stay the same?
  • existing derivative definition helper API preserved, but with new underlying storage
  • same for access API
• Review Guide docs to make sure appropriate for 2.0 release
• #78

Oops!

#129

Cannot edit or delete comments. I believe we discussed deleting functionality made the most sense as opposed to editing them.

I've run into an indexing customization inconsistency...

You can choose what attribute is written to Solr as the "id" field value:

In my Kithe instance, I'm sending along my "layer_slug_s" field value -- GeoBlacklight schema's primary key.

However! You cannot control what record attribute Kithe uses for deletions:

Here, Kithe is just calling directly for "record.id" (the UUID table pk) which causes all my model destroy calls not to delete from Solr.

A fix would be to send the record Kithe.indexable_settings.solr_id_value_attribute value if available, or fallback to record.id.

Cannot run the rspec suite successfully without ffmpeg installed. Should add a line to the dev notes in the README.

Without ffmpeg

With ffmpeg

john cupitt of vips suggests:

Secondly, P3 colourspace is becoming very widely used. This is significantly bigger than sRGB, and P3 images converted to sRGB will either be drastically clipped or desaturated. Either way, your users are likely to complain, especially the photographers.

Rather than forcing everything to srgb, I think best practice now is to strip all metadata except the icc profile.

janko/image_processing#34 (comment)

Kithe comes with some features that end up requiring structure.sql instead of schema.rb. Like the triggers and functions for friendlier_id auto generation, triggers for leaf_representative, etc.

Considering using the fx gem so we can take advantage of those postgres functions while still using schema.rb instead of struture.sql.

Kithe provides some callback-based logic to automatically trigger re-index of Kithe models upon changes -- with features to disable/customize that etc.

But what if you are indexing based on an associated object? For instance, let's say a Work indexes the collection name(s) to provide faceting on collection. Work to collection is many-to-many with a join table.

This would mean Works would need be re-indexed if: A) A collection it belongs to changes it's name, or B) a Work changes what collections it is assigned to.

Right now, there is no way to make this happen automatically, you'd just need to make sure to re-index the work yourself if these things happened.

Should we put model-callback-based automatic logic in to configure things so that if, in that situation, the relevant Works could be automatically reindexed similar to for changes in the Work itself?

It does not need to be just work-collection, it could be any association, possibly even not Kithe::Model, associations to additional entities.

It would be nice if repeatable_attr_input kept this potential label arg in mind when ultimately generating the add_another_text value. Otherwise, you end up with a nice label and a funny "Add another Gbl displaynote sm" link:

I know you can add these field strings into a I18n file, but I specifically don't want to have to do that. I'm pulling all of my form fields, field types, labels, html_attributes, etc. from an ActiveRecord model:
https://github.com/geobtaa/geomg/blob/feature/attribute-model/db/schema.rb#L238-L264

Hoping to find time this week or next for a little PR to support this...