by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 12:36
    shioyama synchronize #387
  • 12:36

    shioyama on extract_reader_writer_into_plugins

    Extract checking available loca… (compare)

  • 12:30
    shioyama synchronize #387
  • 12:30

    shioyama on extract_reader_writer_into_plugins

    Extract checking available loca… (compare)

  • 03:33
    shioyama opened #387
  • 03:33

    shioyama on extract_reader_writer_into_plugins

    Extract reader/writer into plug… (compare)

  • 02:23

    shioyama on plugin_dependencies

    (compare)

  • 02:23
    shioyama closed #386
  • 02:23

    shioyama on master

    Add depends_on for plugins to d… (compare)

  • 00:43
    shioyama synchronize #386
  • 00:43

    shioyama on plugin_dependencies

    Add depends_on for plugins to d… (compare)

  • 00:27

    shioyama on update_master_branch_readme

    (compare)

  • 00:26

    shioyama on master

    Add comment about status of mas… (compare)

  • 00:25
    shioyama synchronize #386
  • 00:25

    shioyama on plugin_dependencies

    Add depends_on for plugins to d… (compare)

  • 00:23
    shioyama opened #386
  • 00:21

    shioyama on plugin_dependencies

    Add depends_on for plugins to d… (compare)

  • May 30 23:43

    shioyama on update_master_branch_readme

    Add comment about status of mas… (compare)

  • May 30 23:41

    shioyama on 0-7-stable

    (compare)

  • May 30 23:41

    shioyama on 0-6-stable

    (compare)

Chris Salzberg
@shioyama
Ok, I'll have a look if you can point to the failing spec. Can you post an issue on Mobility?
Bram Jetten
@Bramjetten
I'm not getting a failing spec when running Mobility's tests
Bram Jetten
@Bramjetten
However, I'm seeing now that your spec says: is valid if no other record has same attribute value in same locale
While what I'm looking for is is valid if no other record has same attribute in *any* locale
I think it's better if I create my own uniqueness validator
Bram Jetten
@Bramjetten
Thinking about it some more, I think it's better to skip the uniqueness-validation altogether. It doesn't do anything meaningful.
Chris Salzberg
@shioyama
Hmm ok
About failing spec, I meant a failing spec in Spina
But also, is valid if no other record has same attribute in *any* locale would be more restrictive no? i.e. if a record is invalid if another record has the same materialized_path in any locale, then if should also be invalid if another record has the same value in the same locale, right? I must be misunderstanding.
Chris Salzberg
@shioyama
Actually, the spec description should really read "is valid if no other record has same attribute value in this locale"
In practice, you generally only change the current locale, so it's the same, but I'm wondering if the validator should maybe check changed attribute and apply the validator for every locale value that has changed...
Bram Jetten
@Bramjetten
You're right, it would make sense if the validation passed.
Chris Salzberg
@shioyama
Even if you decide to remove the validation, I'd like to know why it changed
Bram Jetten
@Bramjetten
We have a presence validation for :title
Bram Jetten
@Bramjetten
If I add uniqueness: true to that validation, it fails in the same way as materialized_path did
Chris Salzberg
@shioyama
ok
Sounds like a bug
Chris Salzberg
@shioyama
I ran the Spina specs and they passed with 0.7.0, was there a failing spec or did you just notice it wasn't working?
Bram Jetten
@Bramjetten
Did you use the master branch?
Because the master branch doesn't include the validation anymore
The 1.0 release should
Bram Jetten
@Bramjetten
I think I got it
Because of .unscoped it doesn't join the translations table anymore
Chris Salzberg
@shioyama
Yes I thought that might be the issue, but it shouldn't matter for the translations table
Anyway it's easy to check if that's the cause
Bram Jetten
@Bramjetten
If I remove unscoped, it passes the specs again
Chris Salzberg
@shioyama
Ah
Indeed, I see the same
I added unscoped because ActiveRecord does that
But I can easily remove it
Bram Jetten
@Bramjetten
Doesn't that cause issues with models with a default_scope?
Chris Salzberg
@shioyama
My understanding was that uniqueness should not depend on default_scope
But I should have looked deeper
anyway I'll yank that out and release 0.7.1
Thanks!
Bram Jetten
@Bramjetten
Awesome thanks!
I think I didn't look carefully enough
Chris Salzberg
@shioyama
Chris Salzberg
@shioyama
So, looking over the code, the question is really "why did Mobility specs not fail".
unscope removes the where clause, which messes everything up (not just Spina).
ok, figured it out. Half of the specs were not even running validations. Thanks for noticing! I'll fix them.
Bram Jetten
@Bramjetten
Awesome, great to see it fixed so quickly!
gcrouillere
@gcrouillere
Hi, @shioyama . I have opened this question on SO : https://stackoverflow.com/questions/51132753/mobility-gem-rails-how-to-perform-a-join-with-like-query-on-a-translated-mod
Could you have a look please ?
Chris Salzberg
@shioyama
Hi @gcrouillere sorry didn't see your comment here but did comment on the SO question. That's really cool that you got the arel to work on that query!
Product.joins(:category).merge(Category.i18n {name.matches_any(categories)})
This is a really nice example of what you can do with the new block query interface.
Chris Salzberg
@shioyama

Hi everyone, just a shout-out to mention I've released 0.8.0: https://rubygems.org/gems/mobility/versions/0.8.0

There's not that much new here for ActiveRecord users, other than new support for order with translated attributes. Globalize supports this; Mobility now does too, for all backends.

For Sequel users, this release includes a complete reworking of querying so that, like with ActiveRecord, you can now use a block format with the query scope (dataset):

Post.i18n { title =~ "foo" }

This is almost the same as Virtual Rows with Sequel, where you can pass a block to where and do some nice querying within the block. For now I have not modified the block format to where so if you want to use translated attributes in your block queries, you need to use i18n (like AR).

Sequel users (I know there are some out there!) let me know if this works (or doesn't work!) for you.

Brice Sanchez
@bricesanchez
Thanks @shioyama !