I have a dataset where I have items, users and list of items that each user likes. Now I would like to suggest a news items to the users.
I would like to use bert4rec or similar model but as I see bert4rec does not care about the the features of the items. All items for it are like a black box with ID.
Can u suggest me what can I do if I want to create smarter model which cares about the attributes of the items (color, size, type...) and so on?
Related
I'm building a SaaS system that allows users to define their own data models and enter data according to those models. It's a bit like airtable.
One user might model a bookshop, and would have a Book model, with title and ISBN fields. Another user might model medical records, and would have "date of last visit" as a field.
In the case of the bookshop, I want users to be able to search on title and ISBN. In the case of the medical records, I want users to be able to search on the date of the last visit.
I am using Firestore as my backend.
Firestore requires an index to enable a search. So that approach will not scale as # of customers increases.
My thought therefore was to have a Firestore instance for each customer, and those specific instances would have the necessary indexes.
I'm sure there are downsides to doing this though.
What would folks recommend to best solve this need?
What you are trying to achieve is some kind of weird, since you will not provide at least a few standard common properties for each user of your Bookshop.
When you want to perform a search in a Cloud Firestore database, you need the exact name of the property on which you want to search for. Having dynamic properties might not help you solve the search feature. However, you can create a document with a property of type array that can hold the name of all properties the users have chosen and perform a search on every property, but this solution will be much too expensive.
In my opinion, a possible solution might be to create at least a few common properties, so you can have the properties on which you can search. When someone creates, for example, a book shop you can display at the beginning all available properties a user can choose. Once you create a shop, you can have different users with different shop properties. This means that if a user does not choose a property, when you perform a search on that property, the results won't contain his/her products. This will work, only if you have predefined properties.
I'm trying figure out the best data model for a items collection in firestore that will allow users to add items they own. I would of course show an items list and then on another page item details so I need to be able to query.
Should I create each user item as its own document with user id inside like so...
Or Since firestore charges on document reads (and each user might have hundreds of items) would it be better to create one document with user id as the document name and then put all the user items in one document like so (each item is a map type (object)....
I am not sure the best way to model this so that is both cost efficent at scale and easy to CRUD and query. Thank you! (sorry for the links, don't have enough rep to inline the images)
I have a content type that references multiple nodes, and I need a way to sort the display of those referenced nodes.
Any ideas?
--- EDIT ---
Clarification:
I'm not using views, but rather am using my own queries.
I have a bunch of teachers (teacher content-type), and some conferences (conference content-type).
Within the conference content-type I want a node-reference field set to handle multiple teacher selections. But I need to be able to manually order them independently. What that means is that each individual conference needs to be able to sort the order of the particular teachers selected.
That's the ideal situation, but not the way I'm actually doing it.
What I'm ACTUALLY doing to jury-rig this thing is to have separate node-reference fields (teacher 1, teacher 2, teacher 3 etc.). Each node-reference field independent of the others.
It makes for a mess when it comes to creating views or composing db queries.
I know what I'm looking for is all but impossible, but I thought I'd run it by the Drupal gurus here anyway...
--- EDIT 2 ---
Further clarification:
Another way to do what I want, but is really impractical, is to create a separate nodequeue for each conference. Then you could select a handful of teachers associated with each conference and order them via the nodequeue. - That should help with visualizing the problem. But as a solution, it's even more messy (in terms of administration) than the one I'm currently using.
Also: I should mention that we're talking about 40 to 80 conferences, and 100-200 teachers. Just to get an idea of why I'm looking for a more elegant solution than the two I mentioned above.
Node reference with autocomplete widget gives you reordering capabilities when number of values set to 'unlimited'. Maybe not the most comfortable, but works.
I'm assuming you're using Views since you mentioned "displays". You can always change the order of the view fields from the Views UI but the order will be static (all items will have the same order).
If you want each item to have a potentially different order for the fields maybe you can set up a parent child relationship where the child item is ordered dynamically.
I have standard basic article content type which, amongst other things, contains an image field which is configured to contain an unlimited amount of values.
I'm now trying to create a view that lists some of the fields in this content type but I want to limit the number of images that are returned for this specific field to 3 random images in the list (or less). Is this something that can be achieved right in my view configuration or do I need to do something ninja? I'm not aware of everything that's possible php wise to "rewrite" / "filter" the results of my view but I'm confortable with anything programming related.
I'm using drupal-7 with Views 7.x-3.0-alpha1
Thanks!
AFAIK there is no way through the Views UI to randomize the selections of a grouped field.
I can see two possible ways, in theory to achieve what you want.
Use hook_views_query_alter to alter the SQL query for the view. I'm not sure Views support what you need to randomize the results, but you have the ability to alter the query that views generates, and might be able to randomize it.
Select all results, but using theming to only show the randomly selected options. This could be done in a preprocess function. Views provides several, depending on your display option, hook_views_view_unformatted might be what you need.
Suppose I have a list of a couple of thousand organizations and a user needs to be able to select one of them. The list is too large to populate in a dropdown at page load, and the user often knows what they want but it's not the first part of the organization name. That is, they know "Collections" but not that the precise name of the organization is "Department of Collections". So the user will need/want to type in some information.
It's easy enough to use an autocompleting textbox of some kind, but I don't want to allow the user to type in random text - they have to choose one of the organizations explicitly.
What's the best solution?
IMO I will simplify the UI to:
a textbox to enter the string
a drop down to set the filter options like: "contains | starts with | ends with"
a button "Find"
Then, I will populate a view based on the search string & let the user choose the valid item or refine the search
IMO with something like an auto-complete, you will end up writing a lot of parsing code to get to the string & then there might be server-side load considerations...
HTH.
In additional check if 'facetted navigation' is something you need. Ref.: http://www.alistapart.com/articles/design-patterns-faceted-navigation/
So it seems to me your main challenges are to
Express that the user needs to select an organization from the list (and only from the list).
Express that there are a lot of organizations on the list.
Provide some means for the user to quickly find the organization on the list.
I would say present a selector control that fits in with the rest of your design with a search box just above it. You should then page the list as there will be lots of pages with that many elements indicating that the user should definitely use the search. The search essentially acts like the auto complete, but instead of the found options changing the text, it will change the contents of the paginated list. If you do this on a character by character basis (or throttle using Reactive Extensions), it's very clear that you're just filtering the list to make selection easier.
You could use a CustomValidator to ensure that the TextBoxes content in contained in your collection.
You could use the Ajax AutoComplete Control: http://www.asp.net/ajax/ajaxcontroltoolkit/Samples/AutoComplete/AutoComplete.aspx. You can opt to only do a lookup if the user has typed in a certain number of characters.
You'd create a static Web Method to query the collection (you could use LINQ) and return matching organizations.
You'd obviously need to validate the textbox input afterwards.
Is it possible to structure your list a bit more like a tree, so that it is not a single list. E.g. Could you have a grouping like "Government Depts" and then add Dept of Collections to that. Then ask you users to first select the top level grouping then show them a shorter lists of organizations in that group?
It sounds to me as if your data list should really be in either a database or at least stored well away from the UI.
Wherever its really stored, place a keyword for each entry, say "Collection". The list of keywords could be available as part of your auto-complete functionality. Then search on the keyword alone.
If you could divide items in categories, would using some kind of tree control help?
So, when user clicks on a node you load only items in that node. And so on.
I'd break it into two paths...
Use an autocompleting textbox, for the person who types the correct title (i.e., Department of Collections); and a separate search button to search for possible matches. The search button would take you to a results page to select the desired choice. This functionality would be similar to the way search on MSDN works.
Initially a tree view sounds cool, but are you certain that a single classification will reduce the data into manageable sets? If 80% of your data gets classified as "government dept" this doesn't really help things.
The problem is you want criteria that allows users to quickly split a large list into smaller sets that are easier to consume. Additionally, there should be enough flexibility to react to changes in data.
I'd suggest using a tagging pattern like iTunes. In my library "rock" describes 80% of my collection - but is still a useful categorization for something like random shuffle. I also have the ability to stack tags so I can use genre="rock", decade="1990" and quickly sift my data down to whatever is of interest.
In the UI, I'd recommend a section that allows the user to apply "filters" which is nothing more than selecting specific values for tags. Break the list out into pages and allow them to see a tally of potential matches.
Scenerio:
- Navigate to screeen XYZ and see there are 10,000 companies to pick from
- Click "classification" and select "Government dept" and the list updates to indicate there are now 1,000.
- Click "region" and select "South" and see my list drop to 200.
- Sort list by name and then select (or scroll through, whatever)