Sherris

Members
  • Content Count

    16
  • Joined

  • Last visited

About Sherris

  • Rank
    Level 2 Stud

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I haven't hit a limit and I've used the API to download the entire part list 100 at a time
  2. Would you recommend then, if I was making an app, to periodically pull the CSV file from the downloads page instead of relying on the API if I wanted to suggest alternate pieces to complete an inventory or build?
  3. So in the above example, isn't 76768 also an alternate for 14395?
  4. In the downloads page (https://rebrickable.com/downloads/) the part_relationships table has child parts and parent parts and relationship type "Mold, Print, Alternate..." In the API, how can I tell what is the child and what is the parent? For example the part 2339 returns this: {"count":1,"next":null,"previous":null,"results":[{"part_num":"2339","name":"Brick Arch 1 x 5 x 4 [Continuous Bow]","part_cat_id":37,"year_from":1986,"year_to":2017,"part_url":"https://rebrickable.com/parts/2339/brick-arch-1-x-5-x-4-continuous-bow/","part_img_url":"https://rebrickable.com/media/parts/elements/4159140.jpg","prints":[],"molds":["14395"],"alternates":["76768"],"external_ids":{"BrickOwl":["853514"]}}]} Where you can see that 14395 is a mold variant and 76768 is an alternate. However when we pull 14395, we see: {"count":1,"next":null,"previous":null,"results":[{"part_num":"14395","name":"Brick Arch 1 x 5 x 4 [Continuous Bow, Raised Underside Cross Supports]","part_cat_id":37,"year_from":2013,"year_to":2019,"part_url":"https://rebrickable.com/parts/14395/brick-arch-1-x-5-x-4-continuous-bow-raised-underside-cross-supports/","part_img_url":"https://rebrickable.com/media/parts/elements/6044725.jpg","prints":[],"molds":["2339"],"alternates":[],"external_ids":{"BrickOwl":["853514"]}}]} which lists 2339 as a mold variant! And for completeness, 76768 returns: {"count":1,"next":null,"previous":null,"results":[{"part_num":"76768","name":"Brick Arch 1 x 5 x 4 [Irregular Bow, Raised Underside Cross Supports]","part_cat_id":37,"year_from":2010,"year_to":2015,"part_url":"https://rebrickable.com/parts/76768/brick-arch-1-x-5-x-4-irregular-bow-raised-underside-cross-supports/","part_img_url":"https://rebrickable.com/media/parts/elements/6012805.jpg","prints":[],"molds":[],"alternates":["2339"],"external_ids":{"BrickOwl":["148046"]}}]} which shows 2339 as an alternate. Which is all to say, how can I tell which is the parent part and which is the child part?
  5. Sherris

    Stickers

    Hi Simon, I enjoyed reading through your detailed thoughts on a solution. I agree with most everything - with questions because I am only making assumptions of the internals of the database. The one main difference i have is adding the stickered variants as spares - I would commit to this and *replace* the plain parts in the inventories with their stickered variants. This greatly simplifies things, despite Nathan's wizardry I think most issues requiring programming come from complicated workarounds to avoid this. So if you add set 9999-1 to your set list, the system assumes you have 3004s001 and not 3004. In fact people who added set 9999-1 years ago will find that their inventory now includes stickered parts. Now what problems might this cause? Currently you can include part variants to see what sets/MOCs you can build. I can include a mix of light gray and light bluish gray parts, and a mix of 1x1 tiles with top clip with rounded tips with 1x1 tiles with top clip with flat tips. Yes, you might need to add a section to https://rebrickable.com/build/ to "ignore stickers", or just roll stickered parts in with printed parts. I'm confused by the "is_stickered" requirement. Probably I just aren't able to see the real tables, but neither the csv parts download or the API has is_printed. Instead I see the parts_relationships table with different rel_type of A, P, and M. To which we can add S. I'm sorry if I'm coming across pushy. I want to understand more and if it's incompatible with the system then so be it. I've just come to understand the stickeres parts in my own collection this way, as almost-printed parts that are distinct from plain parts. Trying to identify stickered parts is excruciating and mostly impossible without proper resources.
  6. Dark Purple is listed in the colors table as 3F3691 That's more of a dark blue: https://www.color-hex.com/color/3f3691 Should it be 6D3691?
  7. Sherris

    Stickers

    I appreciate the idea behind that, and I think it actually opens up a very interesting discussion about user-created parts (MOPs?) If we did track that I think you might see user-created downloadable sticker sheets that have official MOP numbers go mainstream. However pertinent to this topic is not trying to solve every problem in cataloging anything a user might have, but instead everything a user is likely to have. If the user buys and builds a set prior to tearing it down, they are likely to have stickered their parts. If you are buying parts in bulk, there are likely to have stickered parts and then what are they? Garbage? Do you peel the stickers off to get back to a primary part? Or are they actually worth a bit more just like printed parts because they belong to a specific set?If you are putting a set back together to sell you may want to either have the full sticker sheet or include the stickered parts. A stickered part with the sticker on poorly is no different than any other lego part in poor condition. Except that you can pull off the sticker to convert it to a primary part. In my personal part collection I consider any part with coloring or glue residue or tooth marks, etc to be damaged and I'll leave it for my kids to play with but I won't count it towards my inventory. A properly stickered part is not that, though - it's a fundamental part of the set. I guess tl;dr adding stickered variants doesn't solve every problem, but it does create a simple low-code solution to understanding part inventory better fwiw the application i'm putting together for myself has a workaround since I want to keep my part list synced with Rebrickable. It creates a separate table mapping stickered parts to inventories and primary parts and is a bit of a bear to manage in-app, although it sorta works. That's also an option but not one I'd recommend.
  8. Thanks - sorry for the duplicate. I didn't see the other one.
  9. Sherris

    Stickers

    Hi I know I'm late to this conversation. In terms of simple solutions, what would be the downside of creating a new rel_type "s" for stickered parts and adding them as a variation to the primary part? So a 1x2 brick with a specific sticker might be 3004s001. The difference between 3004pr001 and 3004s001 is that it is understood that the printed variant *always* has an image, the stickered variant *may or may not* have an image. This is a simple solution and pardon me if it was considered already, but everything in this thread discussed alternate inventories and grouped "super parts" and focuses on the stickers themselves and not the stickered parts. Advantages: Minimal reprogramming, except to add a new rel_type to the DB and possibly updating the https://rebrickable.com/build/ to specifically treat them differently than printed variants Ability to add photos of stickered parts to make it easier to identify If resorting back into the set, knowing which parts should or may have stickers Doesn't create alternate inventories, just alternate parts, so maybe adding 5-10 new parts per set instead of doubling the DB Does not involve grouped parts Is a permanent solution, not a temporary fix 99% of work is on users to update inventory lists If done properly would be invisible to most users - part inventories would be updated automatically, MOC availability would stay the same, data structure would not change! Complications: When looking at a pile of parts, is the blank brick 3004 or an unstickered 3004s001? I'd say they're functionally equivalent so it doesn't matter. I admit I don't know how power collectors use Rebrickable Stickers that cover 2 or more parts (why lego??) - treat them as 2 separate stickered parts. I'd say in probably 0 cases is the sticker providing structural support so if the set were dismantled (of course it is, otherwise why track parts) the sticker may be or should be cut neatly and be functionally identical. How to handle both sticker sheets & stickered parts? Include both, understanding that the stickered parts may or may not be decorated and the sticker sheets may or may not be used or partially used in your personal inventory. Mitigations: Create a function to swap out stickered variants in a set with primary variants by marking all stickered variants as "lost" and adding primary variants as loose parts
  10. The GET /api/v3/lego/sets/ API has a return field called last_modified_dt which is also sortable. This means that when pulling the full list of sets, you can get only sets that have been added or changed since the last time you looked! This is really handy for a recordset with over 13,000 records! However none of the other APIs have this field, most notably GET /api/v3/lego/parts/ which has over 31,000 records! To update an offline list requires downloading and parsing all 31,000! In the Access DB I'm building, updating the Parts list took over 20 minutes, and I'm sure Rebrickable wouldn't mind avoiding excessive web traffic. Adding last_modified_dt to the API, especially if it's data already saved internally on Rebrickable, should be an easy adjustment.
  11. I'd like to see tracking for stickered parts in inventories. That is, once you put the sticker on for a build, it's really in the same situation as a printed part, which has its own part number. The implication is that if I'm building a MOC I might want to exclude parts I own with stickers on them. On the flip side, if I have a stickered part and I'm trying to figure out what set it belongs to, this would be very helpful.
  12. Hi, I'm trying to use the API to update my Access DB tables. I'd like to ping the server as little as possible during an update - once the tables are downloaded I don't see any reason to pull 14000 sets or 32000 parts 100 at a time. So my tactic is to order by last_modified_dt in descending order and stop paginating once I encounter a date prior to the last update. However I've found that the first 1800 sets in the list have null last_modified_dt that comes up first when I reverse sort on that field: https://rebrickable.com/api/v3/lego/sets/?ordering=-last_modified_dt { "set_num": "313-2", "name": "Bracelet and Pendant", "year": 1979, "theme_id": 668, "num_parts": 40, "set_img_url": "https://m.rebrickable.com/media/sets/313-2.jpg", "set_url": "https://rebrickable.com/sets/313-2/bracelet-and-pendant/", "last_modified_dt": null } Is it possible to filter for last_modified_dt is not null? That said, as a suggestion, it would be great to have a parameter to pull only newly updated records directly.
  13. Thanks Simon. I don't have any points on the site and I don't know how long it would take to get to level 3. Regarding set ID - I saw that Brickset had it as that, but the printed instructions say TRUGATE. I'm not sure why they're different.
  14. Can you add TRUGATE - Jurassic World Gate from Toys R Us (rip)? PDF of instructions: https://www.thebrickfan.com/wp-content/uploads/2015/06/LEGO TRU Jurassic World Gate.pdf I have the paper instructions so let me know if you need a clearer copy. 63 pcs, 2015.