This week, I began by reworking the item API to include the image path and uom name property to the item list dto in order to obtain the item list query. This is crucial because in order to query the item list, the frontend developer requires these properties. Additionally, when I query the item list using the search name as the basis, I also change the regex options. I’ve added the option which tells the item list query to disregard any whitespace users may have inadvertently entered.<\/p>\n\n\n\n
In addition, I eliminate some superfluous DTO that is not really needed when querying item data for barcodes, as this will make the results easier for frontend developers to read. I’ve also introduced more properties, which contains the more sub-properties. In addition, I have updated the item detail dto with the UomName attribute.<\/p>\n\n\n\n
Mr. Peter discovered that after looking over my code, I needed to add the uom functionality to the item API. This is so that it can remember the uom that is being made or added to each thing. I need to know the uom that is within every object. Thus, I’ve added a capability to uom that allows you to obtain uom details or lists by id. Since there would be differences in subprice for each uom, I have further included the subprice attribute for each uom.<\/p>\n\n\n\n
In order to verify the requirement that the entity id and barcode cannot exist more than once, I have finally refactored the item entity API code. In order to prevent the database from returning an error each time a user adds a new item entity with the same barcode and entity ID, I inserted the unique complex key when I created the item entity table.<\/p>\n","protected":false},"excerpt":{"rendered":"
This week, I began by reworking the item API to include the image path and uom name property to the item list dto in order to obtain the item list query. This is crucial because in order to query the item list, the frontend developer requires these properties. Additionally, when I query the item list … <\/p>\n