Originally by: Daedalus II

---

Given all those extra ids you got from the 64 bit conversion, wouldn't it have been easiest to just give the blueprint copies their very own item ids?

Given, you would have to figure out which item id a copy should have given an original with a different id, but this must be easy to add as an attribute to the original?

This would then work universally in cargo holds, in hangars and in the LP store.

---

Originally by: fgft Athonille

---

when are you a*sholes going to fix lag?!

---

Originally by: Ms Freak

---

Question:

If you had a "typeId" column (assuming this makes an DBRow a Blueprint or a Ship or a Gun (etc)) - Why not just add another type "BLUEPRINT_COPY" and reference that?

I obviously missed something in the dev blog, which was very interesting btw, and was wondering why the change took so many changes and effort?

---

Originally by: Arrius Okaski

---

From the Blog post it sounds like the definitions of the blueprint copies were related to the original. (Not the instances of copies)

Could you have created the blueprint copies as their own item type instead of adding a relational link to the definition of the originals?

Have I misunderstood the nature of the relationship between the copies and originals?

Would be cool to get a response :)

---

Originally by: Enthral

---

Originally by: Elsa Nietchize

---

Edited by: Elsa Nietchize on 31/05/2011 17:22:41

Quote:

---

So, saving DB space and bandwidth, these two got merged into an integer 'quantity' column with the new semantic that negative quantities implied a singleton. We just mass-updated the inventory table turning all 'singleton==1' items into 'quantity=-1'.

---

So the quantity value is an integer...
And the maximum value of an integer is 2,147,483,646(signed)
so what happens if i have a stack of ammo greater than this value?

---

Max size of a 64-bit integer in SQL Server (which I believe they are using) is (signed) 9,223,372,036,854,775,807. CCP may be capping the max size of a stack to something else, but the database isn't the limiting factor. To put that number into perspective, if you added one item to your stack every thousandth of a second, it would take you 106.8 billion YEARS to reach the limit. The Sun only has about 5.4 billion years left in its life, and the entire universe is thought to be around 13.75 billion years old.

I do have a question for the developers. Have you done any performance metrics on your change? It has been my experience, that using a virtual column isn't always faster than just doing a join. This is because that function can be called on every row in the table. You might not see a performance issue on your test servers, but as soon as you scale it up to tranquility...

---

Originally by: Wollari

---

Will this singleton flag change (1/2) be readable via API aswell? That would help lots of people with managing their industry and assets externally.

Haven't checked the API yet.

---

Originally by: CCP Prism X

---

Edited by: CCP Prism X on 01/06/2011 08:55:32

Originally by: Wollari

---

Will this singleton flag change (1/2) be readable via API aswell? That would help lots of people with managing their industry and assets externally.

Haven't checked the API yet.

---

As we speak the API simply casts any negative quantity into 1 to avoid screwing with any summing of quantities. When I saw this post yesterday I created a defect on the new API developer that replaced me but I cannot promise when he'll get to that. But he's busy enough with development so I'm posting (also I love posting).. so soonÖ?

I'm not sure how Elerhino (The new API developer.. who is also the old one that I replaced. We're a tag team.) will go about solving this, but I doubt he'll actually change the quantity from displaying 1 unit for any singleton as it will be completely incompatible with any application using the current form of the call. But we're aware of the need for the actual quantity, and the need to keep legacy app arithmetic functioning.

---