Topic: Component CSV export

Guys, come on, component export without item names? And while you're at it, add the following:

  • item exports should have an additional column, with the token name (e.g. CPU usage would be cpu_usage). This to prevent ambiguity, which occurs now on a wide range, severely limiting the usefulness of this export. Please.

  • have this for the component export too

  • item names in all exports (parameters, component, markets)

Many thanks.

Re: Component CSV export

+1

And add the agent name in the extension history csv export too please. Or put it in the file name as you wish.

Re: Component CSV export

+1

Re: Component CSV export

Yeah, either/both in the file name / csv file. Thanks!

Re: Component CSV export

Either improve export system or add an API with a GREATLY improved export system. wink

6 (edited by Doek 2011-08-26 12:44:11)

Re: Component CSV export

Alexander wrote:

Either improve export system or add an API with a GREATLY improved export system. wink

I'd say an API with a static export to query out of makes more sense. But no matter, the only useful static exports we have is extension history and events.

Let me outline this one more time, given the last few patches the point just doesn't come across.

Dear devs, we have the dictionaries from the GBF. We can pull them out at will, so whatever the language, we can make sense of tokens. Tokens are unique, yet their translations aren't. So whenever we export something, we either don't know what they are (there's no unique identifier) or there's 3/4 tokens to choose from based on their ambiguous translation in exports of numerous items (not an ounce/gram of overestimation here). So please, just throw us an actual bone. Tokens, not their translations.

Here's my database so far, for those interested. It's slightly out-of-date, and there's a lot of guesses that is going to bite me in the *** when an official static dump is released. All easily solved by the suggested tweak.

http://dl.dropbox.com/u/7523665/perpetuum-doek.sql

Re: Component CSV export

Thanks Doek! I decided to drop my own DB since yours is more "efficient".

I believe all perpet tools coders should create a public space (possibly on google code or something) so we could share this stuff and maintain it as patches and whatnot come out.

probably the best next thing to getting an actual API.

Re: Component CSV export

Red Bishop wrote:

Thanks Doek! I decided to drop my own DB since yours is more "efficient".

I believe all perpet tools coders should create a public space (possibly on google code or something) so we could share this stuff and maintain it as patches and whatnot come out.

probably the best next thing to getting an actual API.

Or beg for a real database dump..

Re: Component CSV export

I really wish they would add a api to gather market data