Hi, I’m looking for an option to have a metafield which store a list of values longer than 128. Or Is it there a different solution for this?
Thanks,
Hi, I’m looking for an option to have a metafield which store a list of values longer than 128. Or Is it there a different solution for this?
Thanks,
Depends on what the actual goal is https://en.wikipedia.org/wiki/XY_problem ,
For example a common goal is relating products but the Information Architecture is bad by trying to store excess amounts of product references as the goal instead of just referencing a single collection that contains N products as a way to the goal.
Probably need to either be using Metaobjects, or using a JSON metafield where the list is brought in as data prepared first externally under ~64K characters in size, or do it as regular string metafield over the api as that should max at 5M in character lenght.
Hi Paul,
Thank you for your reply. The reason of why I would like to have a list of values longer than 128 is because we are selling electronic components that are used in RV and motorhomes. For one of our customers, which is a motorhome manufacturer, they put numbers to each coach they manufactured. So the items we sell are part for specifics coach numbers, example an item can be used in a range of coach numbers (1739 - 1832), others can be from 693 - 1832. That’s why the use metafields for an easy filter and search but I have that limitation on the number of values I can put on metafield.
I hope this explanation is helpful to have a solution.
customers meaning Vendor (aka brand). who is also the supplier.
crude description of vendor v supplier in shopify but in the context of the stocky app.
Or customer that buys parts from you because this is B2B.
Sight unseen, there’s generally too many moving parts to spend time untangling something like this for all the implementation details needed.
If due to a limit there’s to many values for a metafield used as a filter try to split that data up into different metafields by some further refining characteristic such as year(date of manufacture), batch number, facility, region,etc etc.
Generally saner to do this with collections for products i.e. make a collection for coach #1739 with all it’s parts in that collection.
/collections/coach-1739 or /collections/brand-model-name-1739 etc etc.
Possibly facilitated with tags(limit of 250 per product, limit of 1000 total in liquid templates) ,or individual-metafields per machine id or some other facet.
So if they know the machine get them to a collection , if they know the part get them to a product that’s show the collections that part is in.
If this limit is hit because the XYproblem made metafields become the goal instead of the real goal to help customers find a part for their machine.
Then probably need to just make a sane frontend part look-up/search.
Providing a lookup is a typical approach item to item relationship through search.
Customer scrolling through potentially hundreds of numbers in a dropdown is a bad experience.
If the goal is to help customers find a part for their machine then let customers enter an id for their machine , a model no, model name, etc. Or through the part number they see all the collections/machines a product belongs to either on the /product page. There’s also custom collection-list templates aka collection of collections i.e. www.mystore.com/collections.
Consumers may only care about the parts for their machine; not really about every other machine the part can work with.
Though if need be, or doing B2B such as selling to repair shops , the collections approach can help with that as well by going through the collections a product is in : product.collections. B2B needing part picking may also just need order forms instead of just be able to accept CSV orders.
An advanced alternative is to us a JSON type metafield and add bigger JSON data directly to the product though this doesn’t work with storefront filtering it does get exposed as properties/hashes in liquid templates.
A sidestepping alternative is to use one of the many search apps/services that can aid more advanced data structures than basic shopify features can.
A future approach would be if metaobjects are used for filters.
Good Hunting