EVE Technology Lab

Battle On - More like that feature of using config outside of Yapeal directory was never implemented but I'll look at fixing that so it will look up and over to config directory for a config file as well like it says in the CONFIG.md.

https://github.com/Dragonrun1/yapeal/issues/83
Pushed an update that should work now if you can give it a try Battle On and let me know if it seems to work for you.

Just to make it clear how this works if you have both

myApp/vendor/yapeal/config/yapeal.yaml

and

myApp/config/yapeal.yaml

files then any settings in the later file overwrites any matching setting from the first file and they both overwrite any defaults set from

Wiring::wireDefaults()

. So for example if you have the following:

---
# myApp/vendor/yapeal/config/yapeal.yaml
Yapeal:
    Database:
        database: yapeal1
        userName: IAmADummy
...

and

---
# myApp/config/yapeal.yaml
Yapeal:
    Database:
        database: yapeal2
...

then the merged settings would be:

---
# myApp/vendor/yapeal/config/yapeal.yaml
Yapeal:
    Database:
        database: yapeal2
        userName: IAmADummy
...

and all other settings would use their defaults.

Sorry I didn't have it implemented before but in the thousand other things that went into re-writing Yapeal it just fell through the cracks

Battle On - it's set in Yapeal::wire() if it notices any 'vendor/' directory in the path.

Added setting it in the 'yc' stuff as well. Note you will only see

$dic['Yapeal.vendorParentDir']

if Yapeal has a parent vendor/ directory in its path. It should set it if you are doing something like

$yap = new Yapeal($dic);
if (isset($dic['Yapeal.vendorParentDir'])){
    print 'Parent = ' . $dic['Yapeal.vendorParentDir'] . PHP_EOL;
} else {
    print 'Parent not set!' . PHP_EOL;
}

You would need to use isset etc as $dic is not just a normal array but an instance of Pimple which in many ways can work as an array but doesn't always work well with things like var_dump().

Things like WalletJornal do build history but others like AssetList, or AccountBalance do NOT they are deleted and replaced on a per char/corp basis.

Hi all I know it's been a while really since I added any new APIs so I decided to look at one that has been outstanding for a good long while and see about adding it. I decided MailBodies shouldn't be to hard to do so I did it. It did turn out a little more complex than I had expected because I forgot i was one of the irregular APIs that use rows with attributes and the element value but since it was only one of each I took a short cut there on how to deal with it.

A heads up for anyone using NOTICE level logging in production (btw WARNING is strongly recommended) you will start seeing some log lines about 'CachedUntil is excessively long was given ...' There isn't anything really wrong here just that Yapeal is noticing the 10 years cachedUntil time the API returns. I'll look into it some more and see if I can quiet it down some way if I get a chance.

In other news do to some RL issues I'm going to be having to move sometime in the next week to a month and not sure what kind of Internet connection I'll have or time to do anything so hopefully people that are already using Yapeal can step up and answer any questions on the forums here and I'll see if I can get someone to help with any bug fixing that might come up. One person does have access to Github and has some knowledge and experience with the code so he can probably deal with most things that might come up. He was even asking about if I had anything I want him to work on the other day in Yapeal since he has some time off work so maybe he'll get a couple of things done while I'm dealing with RL for a while .

As always thanks for using Yapeal, Dragonaire

Running 2.0.0 I am finding that all log levels are present in the log file despite having configured Error.threshold = 500 and Log.threshold = 300. The log file seems to top out just north of 100M and the yapeal process stops (after 3.5 hours).

It would appear that your monolog FingersCrossedHandler is not active and all levels from 100+ in your 2x new StreamHandlers calls are being recorded.

I have temporarily changed Wiring.php to set the desired levels.

Is my diagnosis correct and can we have a fix please?

In that case I may have to continue with my customisation. I have a 5+ hr run of data collection. In the first few minutes I get one of:

yapeal.WARNING: Failed to upsert data from Eve API account/APIKeyInfo for due to a "Syntax error or access violation: 1064"

yapeal.WARNING: Failed to upsert data from Eve API corp/CorporationSheet due to the schema not supporting REALLY big corporations (fixed by me) : "Numeric value out of range: 1264"

yapeal.WARNING: Failed to upsert data from Eve API char/ContactList due to weird formatting of names: "Invalid datetime format: 1366"

That FingersCrossed then logs EVERYTHING after one of these is not useful to me - 100MB of logs and eventual failure of the run - I guess due to a log size issue.

Let me say: your code is brilliant and does amazing things for me. Thank you.

Well, after Rhea Yapeal stopped working so I updated the library again (last update was made in November) and I get this:



I searched your repository on github for "FilePathNormalizerTrait" and could only find "use" of it but no declaration at all?

/Edit: According to the master branch on your github, the folder "lib/Filesystem" is gone?
/Edit 2: Great, I just noticed you move the FilePathNormalizer into a seperate repository and as I am not able to use composer to update my project it went just nowhere...

/Edit 3: So I managed to get Yapeal up and running again (more or less a fresh reinstall using composer on my dev machine) and after I truncated the "cachedUntil" times it seems to be pulling fresh data again *crossing fingers*

Today I came across a strange issue.

I noticed that for one of my own chars my site wasn't updating the skill queue so I checked the utilCachedUntil table to find out what's going on.

Both times, for SkillInTraining and SkillQueue showed expiry dates roughly 36 hours into the future. So I checked the dates at 06:30 and they listed times for the next day at 12:46 or so. For short or m-short cache style timers this seemed way off to me.

So I deleted the datasets for my character to see what comes in with a fresh pull:
SkillInTraining 2014-12-12 06:34:33 xxxxxxxx Char
SkillQueue 2014-12-11 06:46:10 xxxxxxxx Char

The timing for SkillQueue seems to be right, for SkillInTraining however, it seems to be way off as the xml I am getting is telling me "cachedUntil" is "2014-12-11 06:42:41" for SkillInTraining.
The time for SkillQueue after the fresh API pull was also off, but only by some minutes (<10 minutes) but it was still not matching the time I got by manually accessing my characters XML using just the URL https://api.eveonline.com/char/SkillInTraining.xml.aspx

Am I missing something here or may this be an issue?

Well you can still try to use "composer update -o" to update yapeal and grab the new project that way if you use composer at all.