member_uid order

[sseerrggii]

Related with #354

Now is ordering by ID alphabetically but we need numerically order

I only see it in produccion, with more than 99 members 😅

[enricostano]

@markets could this be related to the casting to String in your PR?

[markets]

Maybe! I'll take a look this night, but is this the default order when you visit the page, or after clicking the sort link? If we're talking about the later, I'd say yes, since the sort is also implemented via Ransack, probably they use the defined casting for all features (filter and order). If so, I think the only solution will be to remove the (Ransack) sort on that column (I think it wouldn't be a problem, since it was kind of extra 😛).

[sseerrggii]

Hi @markets
Both orders are aphabetic now

• the default order when you visit the page
• after clicking the sort link

[markets]

ok thanks for the info @sseerrggii! I just reproduce it in staging. The weird thing is that I can't reproduce it in my local environment :(

@sauloperez @enricostano what version of PostgreSQL are we running in our current infra? I realized I'm running and old version (9.3), and I suppose this might be related (since I used an internal PostgreSQL helper):

timeoverflow/app/models/member.rb

Lines 3 to 5 in c4fb4aa

	ransacker :member_uid do
	Arel.sql("to_char(member_uid, '9999999')")
	end

About possible solutions:

• NEW Combine search params in controller and use *_eq Re-implement the member_uid searcher #399
• NEW Rename ransacker Re-implement the member_uid searcher (different approach) #400
• Try casting with Arel.sql("member_uid::text") instead of Arel.sql("to_char(member_uid, '9999999')") ¯_(ツ)_/¯
• Remove sort by member_uid, and default to created_at (results should be pretty similar)
• Implement search without Ransack
• Avoid the casting via adding a second input to search by member_uid (not nice UX)

[enricostano]

@markets 9.4.5 in production and 9.5.12 in staging... 😅

[markets]

Hi @enricostano @sauloperez 👋

I think I've found a different fix: #399. Basically: instead of casting that column to string, combine manually the search params to simulate current behavior by using *_eq predicate in that numeric column.

Let me know what do you think.

[markets]

New approach pushed in a different branch, so now we have a couple of solutions, both solve the issue, so we just need to decide what solution we prefer:

• Re-implement the member_uid searcher #399: move member_uid to use _eq by mapping params manually
• Re-implement the member_uid searcher (different approach) #400: rename ransacker to only use the cast when filtering (suggested by @mllocs in Re-implement the member_uid searcher #399 (comment))

I think I like more the second one :)

[enricostano]

Many thanks @markets and @mllocs for dealing with this, I also prefer the second option 💪