I am implemeting Lucene for an ecommerce system and need to index the products along with their attributes. However, I'm not sure how to approach this as every product will have a totally unique attribute list.
Most examples online show a lucene access layer with a product structure such as Name / Title / Description, sometimes even with a custom field which just gets added for every product.
An example of two products that would need to be indexed are shown below. As you can see in this case (although not always) there are similar attributes, but also unique ones.
ID - 1
Product - Electric Shower
Name - Triton t80Z
Description - Details about shower here...
Attributes
Color - Black
Power Rating - 7.5Kw
Temperature Control - Manual
Water Entry - Top Left
ID - 2
Product - Digital Shower
Name - Grohe Grotherm
Description - Details about shower here...
Attributes
Color - Chrome
Temperature Control - Thermostatic
Water Entry - Top Left
Flow Limit - 8 Litre/min
LCD Display - True
Control Panel - Wireless
Control Panel Range - 10m
Given this situation, how would I index the above products and create a query in lucence to find any products across the site that contain a Temperature Control attribute which is Thermostatic?
Unlike with databases, Lucene has no schema (at least in the classical DB sense) so you are free to add any attributes (they're called fields) at any given time. Just create a new Field, with the relevant name/value, add it to the Document and that's it.
Q> how would I <..> create a query in lucence to find any products across the site that contain a Temperature Control attribute which is Thermostatic?
A> something along the lines of the following should just work, providing you will use the same analyzer which is used for indexing the document:
Query q = new AnalyzingQueryParser(<params>).parse("temperature_control:Thermostatic");
Going deeper into details, it depends if values for Temperature Control come from a pre-defined list, and how you want them to be searchable (exact match VS separate words, etc.). These will define settings for your analyzer.
Related
I have question about how to organize API route structure. Have read many books about building RESTful APIs and couldn't find answer for that.
Every book tells about simple CRUD actions, and nested resources in one level.
Like /users and /users/1/posts. No problem with that.
EXAMPLE:
But let's look at more difficult real life example:
GET /cars // List of cars
GET /cars/{car_id} // Get single car
POST /cars // Add new car
PUT /cars/{car_id} // Update existing car
DELETE /cars/{car_id} // Delete car by specified ID
Structure for database table of cars would be
Table "cars"
- id
- uuid
- make
- model
- year
- created_at
- updated_at
- deleted_at
No problems so far, but then I need to add nested resource.
All repairs that were done with specified car.
GET /cars/{car_id}/repairs // List of repairs that were done with car
GET /cars/{car_id}/repairs/{repair_id} // Get single repair
POST /cars/{car_id}/repairs // Add new repair for specified car
PUT /cars/{car_id}/repairs/{repair_id} // Update existing repair for specified car
DELETE /cars/{car_id}/repairs/{repair_id} // Delete repair by specified ID
Structure for database table would be
Table "car_repairs"
- id
- uuid
- car_id ( foreign key to cars )
- title
- description
- repair_started_at
- repair_ended_at
- created_at
- updated_at
- deleted_at
So far no problem. Like in all books. a /users route and nested route /users/1/posts. But then here starts problem, when I need to add another level of nesting.
I need CRUD routes for all defects that were found when car was on repair
GET /cars/{car_id}/repairs/{repair_id}/defects // List of all defects that were found for specified repair for speicified car
GET /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Get single defect
POST /cars/{car_id}/repairs/{repair_id}/defects // Add new defect
PUT /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Update existing defect
DELETE /cars/{car_id}/repairs/{repair_id}/defects/{defect_id} // Delete existing defect
Table structure would be:
Table "car_repair_defects"
- id
- uud
- car_id
- repair_id
- name
- description
- created_at
- updated_at
- deleted_at
QUESTSIONS:
What to do here, is level of .../defects normal practice or not ?
Consider situation if I need to add another, 4th level of nesting, at example, all parts that were used for found defect
What best practice when nesting resources in RESTful API's
One can say that this can be done without nesting. Example /cars /repairs /defects /parts But then, what about RESTful examples with nested resources. Then what is maximal level of nesting resource 0, 1, 2, 3 ?
Also if it will be done without nesting, at example, you need to create dictionary route /defects that just lists all possible car defects. So there would be name collision.
Also, if there is no nesting, how would you filter items, that you would filter with nesting ?
defects?car_id=1&repair_id=2&defect_id=3
Like this ? This looks ugly.
Please can someone point to a book or article, or give answer about maximal level of nesting and questions listed before.
Thank you.
Here's the key point: REST doesn't care what spelling you use for your identifiers.
Which is to say, REST considers each of these URI to be equally good.
/cars/{car_id}/repairs/{repair_id}/defects
/08617423-cc74-4967-9a67-49e4171f01b7
As far as the client is concerned, the identifier is opaque; encoding information into the URI is done at the discretion of the server for its own exclusive use.
Beyond that, identifier spelling conventions are effectively code style conventions; use spellings that are consistent with the local style.
From the client's perspective, the identifier does not describe the semantics of the resource; that's the job of the hypermedia representation.
I need help to model a database in MongoDB.
The model below shows performance problems.
- Collection users
- email
- hash
- store
- name
- adress
- logo
- products
- name
- value
- description
- image
- featured
- categories
- id_category
- Collection category
- id
- name
In the system the user can have a shop and the shop have many products and the products have many categories.
The problem is when I want to put a product featured on the home page , the system will search for all users , which is not good.
I thought about putting the products in another collection , but that would think of " relational " mode, which MongoDB is not .
You can do relational in MongoDB it just isn't build with that in mind so you will have to pay attentions to the things that relational databases would usually pay attention to for you and you will also have to work arround things that are missing like joins. But that doesn't mean you can't do relational and if you look at your schema you are already doing the categories relational.
Also since you are storing images with the product and a shop can have a lot of products you will probably run into the 16MB document size limit sooner or later.
A product collection is probably the right way for you given the information from the question.
Since your user have many products, I think its better to put "product" in another collection.
Note that MongoDB has a limit of 16 MB for a single document.
You can do something like the following:
- Collection users
- email
- hash
- store
- name
- adress
- logo
- products :[product1ID, product2ID,...]
- Collection Product
- ProductID
- name
- value
- description
- image
- featured
- categories
- id_category
- Collection category
- id
- name
Embedded document model is not a good choice for many-to-many relation. Using normalized data model can clarify the schema, save disk space. Although you would have to run multiple queries for a "JOIN".
For more detail, you can read the data model section of the official manual:http://docs.mongodb.org/manual/core/data-modeling-introduction/
Our factory rates employees by using 5 ranks:
rank1 - Uncertified
rank2 - Certified
rank3 - Instructor
rank4 - Master Instructor
rank5 - Supervisor
I want to have a layout where 3 fields need to be shown:
1) First field - Drop-down list which shows only employees with rank1
2) Second field - Drop-down list which shows only employees with either rank3 or rank4
3) Third field - Drop-down list which shows only employees with rank5
I don't know how to make each field conditional using the above conditions
I have set up 3 tables:
rank: _pkRankID, RankName
employee: _pkEmpID, EmpFname, EmpLname, _fkRankID
trackingform: _pkFormID, FormDate FormComments, FormRating, _fkEmpID
I am getting very frustrated trying to figure out what fields to use and how to set up a conditional statement. I either get a ? or a 0 (zero) or nothing in my Drop-down box.
Could someone walk me through step-by-step how to do this please?
Based on your description, I put together a sample file that accomplishes this.
It involves:
Creating several global fields, corresponding to the appropriate rank ID
Create several Table Occurrences on the Relationship Graph, with relationships based on the global fields
Create several value lists, which pull from the Table Occurrences you created
You can download the sample file at http://cris.lc/pcuf4
My CMS is currently Movable Type 5.04. The attached screenshot is how I check in Compose Screen of MT CMS.
And it appears in the new entry create page with the following order.
- Location 5
- Job Description 5
- Bio 5
- Job Title 5
I would like to change the order into following.
- Job Title 5
- Location 5
- Job Description 5
- Bio 5
Is there any way to do so? I have checked in the cfg_entry.tmpl file and the above Entry fields were not there as there were custom fields. Could you please help me sort them like above?
the order of the fields are stored into the permission table, in 'permission_entry_prefs' field. (and there is a matching field for the page)
the row with blog_id 0 is the user defaults, and each blog's raw will override the default for this blog.
and the format is very simple: comma delimited list. you should find there something like "title,text,tags,assets". just reorder them for your liking.
If the user will toggle on and off fields, I'm not sure if the original order will return or not. if it does, then a simple plugin can solve it in more permanent way.
I remember doing this by recreating the custom fields in the wanted order (MT pulls them from the DB in a specific order, sorted by ID IIRC). If you have existing data, then you need to delete the fields definitions (not the data) then recreate them in the order you want changing just their numerical ID (not anything else).
I'm traveling and busy at the moment so can't dig into details. But study how CF are defined in the DB and how to simply reorder them by ID.
A client has asked if they can prioritise a certain product in their online catalogue so that it appears as the second product rather than the sixth or so. Is this possible?
This is all I can find in the help section, which points to a no answer.
Customizing how sub-catalogs list appears
{tag_cataloguelist,rowLength,targetFrame,notUsed,sortType,hideEmptyMessage,list/table}
rowLength Number of catalogs per
row targetFrame e.g. _blank.
Specify the frame you want the product
to open in resultsPerPage
Number of catalogs you wish to display
before the page paginates
notUsed this field is not currently
used. Leave empty. sortType
- Alphabetical
- Weight (Defaut) hideEmptyMessage if a catalog does not
have any sub-catalogs you will see a
message This catalog has no
sub-catalogs. You can hide it by
setting it to true.
Hopefully I'm just missing a really obvious control in the BC interface somewhere.
So that help documentation you've pulled up is regarding catalogs. If you want the catalogs to appear in a different order, use the "Weight" sortType in your tag_cataloguelist and assign weights to your catalogs when setting them up.
For individual products in the list view, assign a weight to each product under eCommerce > Products in the detailed product settings. You can also assign weights in bulk by downloading the entire product list then reimporting the product database.