I have a very basic, functioning, checklist application that I'd like to improve.
Essentially, it's just a list of 37,000 (and growing) items.
Right now, I have two entities:
1) Checklist: This includes the following attributes: name, numberOwned, imageName, groupName, etc - 14 in all. All are Strings
2) Keywords: This includes a single attribute: words, with a one-to-many nameKeywords relationship. This stores the normalized name for searching
My question is: Is there any reason to be using multiple entities in this type of situation? Should I remove the Keywords relationship and just add that as an additional attribute? Or should be be going the other route, minimizing the attributes and adding more entities?
I'd like to keep it as simple as possible (I'm not an experienced programmer, and the app isn't a source of revenue - it's available free on the store) - but I would like to make the searches more efficient if possible to make my users happy. Right now when a user searches for an item, it searches the normalized name in the Keyword entity, but it can take a while if they are trying to search through all items.
As usual, I apologize if this question is to vague. I'm happy to provide clarifications and code snippets as needed!
Zack
To increase the speed of search, you can use indexes for attributes, but it'll help if you can show your model of database
Related
I am an experienced full-stack web dev, but new to PimCore. I’m organising a large catalogue of many types of items in PimCore and have looked through the documentation many times, but I still don’t know how to tackle two basic issues I have organising my product data into classes. I hope some more experienced PimCore users or devs can shine some light on this.
Issue 1: how to model general product attributes that apply to all products in the catalogue.
All of the products in my catalogue will have a name and a description, so I thought it made sense to make a Product class that has these fields and make all of my specific product classes subclasses of that Product class so I wouldn’t have to add name and description fields to each subclass individually.
I tried to set this up, but in the object editor of the specific subclass the layout fields that I added to the generic Product superclass don’t show up. Am I missing something here? Should my approach actually work? If not, what would be the PimCore approach to modelling this?
Issue 2: how best to model products with multiple options, ie. variants over more than one dimension.
For example, T-shirts with both color and size options (let’s say, 3 colors and 3 sizes for a total of 9 variants). I would want to create one single T-shirt product in the object tree and then add 3 color options and 3 size options for an (automatic) total of 9 variants. I want the T-shirt to appear as a single product in the e-commerce frontend and let the end customer determine the value of both options.
I am wondering if it is at all possible to do this in a way that allows me to specify the 3 color options and the 3 sizes independently of each other. The examples I find in the documentation all show me a fully expanded object tree covering all options (eg., 1 T-shirt object, with 3 subobjects for each size, each with 3 subobjects for each color in that size). Although data inheritance helps with the management of this info, a change in the available colors would still have to be made once for every size option. I can’t imagine there is not a better way to set up object variants in multiple dimensions in PimCore, but days of searching have led me nowhere. Am I missing something here? Or does PimCore actually force you to create objects/variants for every combination of product options? If not, what would be the PimCore approach to modelling this?
I hope someone with a little experience in this field is willing to shed some light on these two issues. Thank you so much!!
Received very helpful answers on the PimCore forums, by user fash:
Issue 1: Pimcore DataObject classes cannot inherit from each other. The way to go would be to create one product class (that
contains all common product attributes) and then use object bricks or
classification store groups to model category specific attributes.
Then on object level, the corresponding object brick or classification
store group can be added to the product object (depending on its
category or other criteria).
Issue 2: As you already noticed, the default way of dealing with different variants of a product is to create an object instance for
each variant and utilize data inheritance to reduce data maintenance
effort (like in the demo). Also as Andrew already pointed out, adding
some helper functionality like a generate variants button is easily
possible.
The reason why we create a unique data object for each variant most of
the time is, that normally each SKU has a unique product number and
also in terms of e-commerce it needs to be possible to reference the
exact variant that was ordered. As an alternative you of course could
use data structures like field definitions or block to follow your
approach and have to attributes (like color, size, etc.) and add
multiple values to them and then deal on the output channel with the
variant generation. It is really up to your use case and your system
what fits better.
An hybrid solution would be to define possible variants with variant
attributes, and then generate the actual object variants on the fly
when one is ordered.
I am trying to create a N:1 relationship off another entity to Order Product. It is not an option in the pick list. I then tried to go to Order Product and create a 1:N relationship and it also does not allow it.
I am sure this is by design from Microsoft, but is there a way to achive this? I perfer not to to a 1:N or N:N as a work around since it will create grids on the form (and that does not make much sense from a UI perspective when there will only be one record).
Thank for the help!!!!
I am going to add a single line of text field and format it as a url. Then link it to the related entity by dynamically populating a URL to the entity. It is a work around but of all the possible scenarios its the best for my situation
We faced the same problem during building a solution for a client. It was a heavy restriction so in the end we just created our own order product entity and linked it via a one to many to order.
This gave us complete control over it and could add relationships as we wish.
This came at a cost unfortunately as you lose the auto calculation on order for example. This wasn't an issue however as we didn't need it or any of the price list functionality.
If this is an option for you I'd recommend doing it this way.
I think that everybody had to face the same problem in his CRM life.
For CRM, the entities, salesorderproduct... are entities used only to enumerate the products of the entity related in its name, and you can not do almost nothing, that's another problem with a workaround, that I'll try to explain, just to see if this could be the solution to creating relations with them, but I don't think so.
The problem is that you can not use the assign functionality as in other relations to copy data from one entityproduct to the lower-level entityproduct when you create custom fields, and you want to copy throught the entire workflow of sales section. In this case, there is no option to enter the "Assign" window (I use Assign because I have always worked in Spanish) and create the field mappings between them.
This could be done by searching the GUID of the "Assign" window, and copyign into any of the URLs of the "Assign" window, the window showed up, and you could do your custom mappings.
I hope this could help, although this question is too old, so I hope other that arrive here, could see more opinions :)
See you
I'm creating a Book store in Magento and am having trouble figuring out the best way to handle the Authors of a Book (which would be the product).
What I currently have is an Attribute called "authors" which is multi-select and a thousand [test] values. It's still manageable but does get a little slow when editing a product. Also, when adding an option/value to the authors attribute itself, a huge list is rendered in the HTML making this an inefficient solution.
Is there another approach I should take?
Is it possible to create an Author object (entity type?) which is associated to a product through a join table? If yes, can someone give me an explanation about how that is done or point me to some good documentation?
If I'd take the Author object approach, could that still be used in the layered navigation?
How would I show the list of all books for a single author?
Thanks in advance!
PS: I am aware of extensions like Improved Navigation but AFAIK it adds something like attributes to attributes themselves which is not what I'm looking for.
For Googlers: The same would apply for Artists of a music site or manufacturers.
If you create an author entity type, you'll just increase your work trying to add it to layered navigation, and I don't see a reason why it would be faster.
Your approach seems the best fit to the problem, given the way Magento is set up. How are you going to display 1,000 (which presumably pales in comparison to the actual list) authors in layered navigation?
Depending on the requirements, you could go the route of denormalizing the field and accepting text for it. That would still allow you to display it, search based on it, etc, but would eliminate the need to render every possible artist to manipulate the list. You could add a little code around selecting the proper artist (basically add an AJAX autocomplete to the backend field) to minimize typos as well.
Alternatively, you could write a simple utility to add a new artist to the system without some of the overhead of Magento's loading the list. To be honest, though, it seems that the lag that this has the potential to create on the frontend will probably outweigh the backend trouble.
Hope that helps!
Thanks,
Joe
I'm trying to write a MQL query to format a search result in freebase (the "output" parameter in the search API). I essentially want to find the (simple) values of all the properties of a given search result (without knowing anything about the types of the result a priori). By "simple", I mean only the default properties if the values are complex objects.
E.g., if I search for "Yo La Tengo" and this takes me to the result for "/en/yo_la_tengo", I want to be able to get the group's members (I just need names, not instruments or dates started), albums (again, just names), films contributed to (again, just names), etc.
Is there a simple way to do this with a search output query, given that I know nothing about the types? I imagine there's some sort of reflection magic I can use, and I've tried mucking about with "/type/reflect", but I'm not getting anywhere. I'm brand-new to MQL (though I have extensive SQL experience), so this is a little daunting. Any ideas?
Edit: So to clarify, I think the problem I'm seeing is due to mediator types like "performance" (an actor in a film) or "marriage". E.g., with a query about Yo La Tengo, I can see most (all?) information that I'm interested in, but a similar query about [The Muppet Movie]( freebase.com/api/service/search?limit=1&mql_output=%5B%7B%22%2Ftype%2Freflect%2Fany_reverse%22%3A%5B%7B%7D%5D%2C%22%2Ftype%2Freflect%2Fany_master%22%3A%5B%7B%7D%5D%2C%22%2Ftype%2Freflect%2Fany_value%22%3A%5B%7B%7D%5D%7D%5D&query=The%20Muppet%20Movie -- sorry, SO thinks I'm a spammer so I can't make this a link), I don't see Frank Oz reference at all (probably because his performance is referenced instead). Is there a generic way for me to "follow" mediator types to get all their properties? E.g., is there a single output MQL that would allow me to get the actor in a performance (when linked form a film search result) and give the the spouse in a marriage (when linked from a person)?
Querying not only every property, but then following those properties another ply deep in the graph for all search results is going to be an incredibly expensive operation. What is the use case for this? Do you really have a UI where the user can see and effectively absorb all this information? To answer the question directly though, it's not possible to unpack mediator types automatically using mql_output on the search API.
I'd suggest combining a basic set of information on the search query with a deeper set of information on a topic that the user has expressed interest (e.g. by hovering over). This UI experience would be similar to that of Freebase Suggest.
In the years since the question was originally asked there have been some additional useful things added such as the "notable" pseudo-property which lets you see what the topic is notable for.
Of course everyone also needs to be moving to the new API, so the queries would be:
https://www.googleapis.com/freebase/v1/search?query=%22the%20muppet%20movie%22&limit=1&indent=true
https://www.googleapis.com/freebase/v1/topic/en/the_muppet_movie
AFAIK there is no way to do this in outright MQL, but you can:
Get all the properties of an object or type of object, then
Programmatically construct another MQL query to get those objects you want to know more about.
Look at this example:
[{
"type|=": [
"/film/actor",
"/tv/tv_actor",
"/celebrities/celebrity"
],
"*": [{}]
}]
It grabs all the properties of all objects that have the type actor, tv_actor, or celebrity. When you run it, you'll see all the possible "follow" points you can explore.
This is not exactly what you want, but it should get you closer.
I'm sure this has already been asked and answered so I apologize in advance for that but I'm not figuring out the correct keywords to search for. Searching for "Pattern" hits way too many Q & A's to be useful.
I'm working on a regression testing app. I'm displaying a form on the screen and according to which user is logged in to the app some of the fields should be read-only. So I can abstract a field object and I can abstract a user object but what pattern should I be looking at to describe the intersection of these two concepts? In other words how should I describe that for Field 1 and User A, the field should be read-only? It seems like read-only (or not) should be a property of the Field class but as I said, it depends on which user is looking at the form. I've considered a simple two-dimensional array (e. g. ReadOnly[Field,User] = True) but I want to make sure I've picked the most effective structure to represent this.
Are there any software design patterns regarding this kind of data structure? Am I overcomplicating things--would a two-dimensional array be the best way to go here? As I said if this has been asked and answered, I do apologize. I did search here and didn't find anything and a Google search failed to turn up anything either.
Table driven designs can be effective.
Steve Maguire had few nice examples in Writing Solid Code .
They are also a great way to capture tests, see fit .
In your case something like:
Field1ReadonlyRules = {
'user class 1' : True,
'user class 2' : False
}
field1.readOnly = Field1ReadonlyRules[ someUser.userClass ]
As an aside you probably want to model both users and user classes/roles/groups instead of combining them.
A user typically captures who (authentication) while groups/roles capture what (permissions, capabilities)
At first blush it sounds more like you have two different types of users and they have different access levels. This could be solved by inheritance (PowerUser, User) or by containing a security object or token that sets the level for the user.
If you don't like inheritance as a rule, you could use a State pattern on the application, Decorate the user objects (Shudder) or possibly add strategy patterns for differing security levels. But I think it's a little early yet, I don't normally apply patterns until I have a firm idea of how the item will grown and be maintained.