Keskustelu: Ohjelmointikysymykset: REST kutsun response bodyn filteröinti ilman foreach looppia PHP:lla

walkout_ [14.04.2022 09:36:39]

i4ware Software on nyt iware Oy, koska sain nyt kaverini ostamaan i4ware Softwaren koko liiketoiminnan ja olen nyt iware Oy:n Tj.

Kehitetään Timesheet for Jira kokonaan uudestaan, koska läheskaikkien asiakkaiden palaute on olut "Confusing Intreface" eli asiakkaat eivät ymmärrä miten koko sovellusta käytetään, yms. Ja käyttöliittymässä on ollut paljon bugeja.

Nyt meidän Hallitksen Pj vastaa tuotten uudella nimimellä Radib Timesheets for Jira markkinoinnista ja suunnittelusta uuteen uskoon.

Esim. yksi paha bugi on ollut se, että ajan Jira Cloud REST API:n palauteet foreach-loopin läpi mikä hidstaa sovelluksen käyttöä.

Alla kaksi koodia jolla en saa haluammaani lopputulosta:

$filteredArray = array_filter(Zend_Json::decode($body), function ($var) {
        return $var['worklogs']['author']['displayName'] === $author && date('m-d-Y', strtotime($var['worklogs']['started'])) === date('m-d-Y', strtotime($year."-".$month."-".$day));
});

$filteredArray = array_filter(Zend_Json::decode($body), function ($var) {
        return $var['worklogs']['author']['displayName'] === $author && ($var['worklogs']['started'] >= date('Y-m-d\TH:i:sO', strtotime($year."-".$month."-".$day." 00:00:00")) || $var['worklogs']['started'] <= date('Y-m-d\TH:i:sO', strtotime($year."-".$month."-".$day." 23:59:59")));
});

Eli sovellukseen tulee vain viikkonäkymä allekkaen Amerikkaiseen tapaan Sunnutaista Lauantaihin ja koodin pitäsi tehdä sama kuin allaolveva foreach-looppi:

foreach ($phpNative['worklogs'] as $key => $value) {

				if ($value['author']['displayName']==$author) {

					//echo date('m-d-Y', strtotime($value['started']));

					if (date('m-d-Y', strtotime($value['started'])) === date('m-d-Y', strtotime($year."-".$month."-".$day))) {

						$hours = $value['timeSpentSeconds'] / 3600;
						//$html .= '<td colspan="5">'.date('m-d-Y H:i:s', strtotime($valueWorklog['started'])).'</td><td colspan="10">'.$valueWorklog['author']['displayName'].'</td><td colspan="13">'.$valueWorklog['comment'].'</td><td colspan="'.$span.'">'.$hours.' h</td>';
						$json['worklogs'][$aa]['id'] = $value['id'];
						$json['worklogs'][$aa]['key'] = $issueKey;
					    $json['worklogs'][$aa]['date'] = date('m-d-Y', strtotime($value['started']));
					    $json['worklogs'][$aa]['starttime'] = date('H:i:s', strtotime($value['started']));
					    $json['worklogs'][$aa]['started'] = date('m-d-Y', strtotime($value['started']))." ".date('H:i:s', strtotime($value['started']));
					    $json['worklogs'][$aa]['description'] = $value['comment'];
						$json['worklogs'][$aa]['hours'] = $hours;

						$aa++;
				   }
				}

			}

Kiitos jo etukäteen jos joku viitsii neuvoa ilmaiseksi vaikka kyseessä on kaupallinen hanke.

Teuro [14.04.2022 10:18:46]

Laitatko varmuuden vuoksi vielä muutaman esimerkin mitä muuttujissa $phpNative ja Zend_Json::decode($body) on sisältönä tarkalleen. Muutoin näyttää vähän purkkamaiselta kasaamiselta. Erityisesti miksi – ilmeisesti aikaleimaa – muutellaan päivämäärämuotoon, vaikka sitä voisi käyttää ihan sellaisenaan. Myös kiinnostaa mitä muuttujissa $year, $month ja $day on sisällä. Jos niissä on kuluvan päivän tiedot, niin olisi helpompaa käsitellä myös kuluvaa päivää aikaleimana.

walkout_ [14.04.2022 10:29:01]

Tässä

try {
				$phpNative = Zend_Json::decode($body);
			} catch (Zend_Json_Exception $e) {
				$json['success'] = false;
				$json['msg'] = $e->getMessage();
			}

ja $year, $month, $day muutujista tulle saman nimiset $_POST muuttujat.

Eli ks. muutujat ovat otsikon mukaisia integerejä.

Teuro [14.04.2022 10:48:42]

Siis mitä noissa muuttujissa on datana sisällä. Se miten niitä eri paikoissa käsittelet ei ole tärkeää. Halutun toiminnan toteuttaminen on helpompaa, kun tietää mitä data sisältää.

walkout_ [14.04.2022 10:52:51]

Eli esim. $year = 2022, $month = 4, $day = viikon ensimmainen sunnuntai intinä.

Teuro [14.04.2022 10:56:56]

Siis nuo taulukot tässä ovat ne keskiössä olevat muuttujat. Niiden täsmällinen sisällöstä olin kiinnostunut.

walkout_ [14.04.2022 11:02:28]

Tarkoitatko tällaista komentoa?

print_r(Zend_Json::decode($body));

En voi postata sitä julkisesti, koska se sisältää luottamuksellasita tietoa.

Teuro [14.04.2022 11:06:01]

No millaisia otsikoita tuossa taulukossa on? Eniten ihmetyttää miksi

<?php
$var['worklogs']['author']['displayName'];

mutta toisaalta

<?php
$var['worklogs']['started']

Eli miksi välillä datassa on ['author'] ja välillä ei. Voisiko ongelma liittyä tuohon. Ja toisaalta voisiko dataa käsitellä vaikka oliona, jossa muuttujat ovat kyseisen olion omia jäsenmuuttujia. Tällöin käsittely voisi olla muutenkin helpompaa.

walkout_ [14.04.2022 11:10:02]

Ylemmässä koodissa on käyttäjän kokonimi.

Alemmassa koodissa päivämäärä tässä formaatissa 2013-05-05T16:34:42+0000

Eli ylempi koodi toimii jo ja listaa vain käyttäjän Matti Kiviharju work-logit.

Teuro [14.04.2022 11:28:50]

Yritän vielä kerran laita sen $phpNative taulukon täsmällinen rakenne esille. Jos data itsessään on arkaluonteista, niin ne voit hyvin poistaa tai keksiä uudet arvot. Sen jälkeen sopivan filtterin rakentaminen on hyvin yksinkertainen toimenpide.

walkout_ [14.04.2022 12:00:42]

Teuro kirjoitti:

Yritän vielä kerran laita sen $phpNative taulukon täsmällinen rakenne esille. Jos data itsessään on arkaluonteista, niin ne voit hyvin poistaa tai keksiä uudet arvot. Sen jälkeen sopivan filtterin rakentaminen on hyvin yksinkertainen toimenpide.

Teuro [14.04.2022 13:42:57]

Näethän itsekin tuosta rakenteesta, että worklogs-indeksiä seuraa laskuri-indeksi, eikä author-indeksi. Nuo filtteriviritelmät eivät siis voi toimia. Foreach-rakenteessa olet sen näemmä huomioinut aivan oikein.

Toisaalta data tulee varmaankin tietokannasta, joten voisiko hakea suoraan se mitä tarvitaan, vai onko tarvetta saada kaikki worklogit esille?

walkout_ [14.04.2022 14:01:37]

Teuro kirjoitti:

(14.04.2022 13:42:57): Näethän itsekin tuosta rakenteesta, että...

Joo data tulle tuolla silmukalla n. 4-8 sekunnissa kaikki päiväkohtaisiin talukkoihin eli 0.5-1.0 sekuntia per talukko ja se on meidän milestä liian hidasta.

Metabolix [14.04.2022 17:26:27]

Jostain syystä tuntuu, että olisi käsitelty tätä ihan samaa asiaa jo aikaisemmin parin viime vuoden aikana?!

Varmaan suurin ongelma ei ole oikeasti foreach-silmukan käyttö vaan silmukan sisällä oleva järjetön date- ja strtotime-funktioiden käyttö.

Esimerkiksi omalla koneellani miljoonan kierroksen silmukka parilla taulukko-operaatiolla vie noin 0,05 sekuntia, miljoona kertaa date vie 0,45 sekuntia ja miljoona kertaa strtotime vie 0,95 sekuntia. Eli jos yhdistetään silmukan sisään 6× date ja 6× strtotime, kuten sinun koodissasi on, niin strtotime vie 5,7 sekuntia, date vie 2,7 sekuntia ja itse silmukka muuten vie 0,05 sekuntia. Ymmärrät varmaan, että ongelman ratkaisu ei ole silloin array_filter vaan tehokkaampi aikaleimojen käsittely.

Hyvin yksinkertaisesti nämä 6+6 funktiokutsua voi tiivistää 1+2 funktiokutsuun, plus yhdet ennen silmukkaa.

$accept_date = date('m-d-Y', strtotime($year."-".$month."-".$day));
// WTF, eikö tämä voisi olla "{$month}-{$day}-{$year}" ilman funktioita?

foreach ($phpNative['worklogs'] as $key => $value) {
	if ($value['author']['displayName'] == $author) {
		$started = strtotime($value['started']); // 1 strtotime
		$started_date = date('m-d-Y', $started); // +1 date
		if ($started_date === $accept_date) {
			$started_time = date('H:i:s', $started); // +2 date
			$json['worklogs'][] = [
				'id' => $value['id'],
				'key' => $issueKey,
				'date' => $started_date,
				'starttime' => $started_time,
				'started' => "{$started_date} {$started_time}",
				'description' => $value['comment'],
				'hours' => $value['timeSpentSeconds'] / 3600,
			];
		}
	}
}

Jos tästä haluaa vielä optimoida, kannattaa miettiä tuon if-lauseen toteutusta jotenkin niin, että ei joudu käsittelemään päivämääriä näillä hitailla funktioilla pelkän vertailun takia. Esimerkiksi onko päivämäärä valmiiksi muodossa Y-m-d (eli 2022-04-14), jolloin yllä $accept_date voisi olla samassa muodossa ja if-lauseeseen riittäisi 10-merkkisten merkkijonojen vertailu (str_starts_with tai substr_compare)? Silloin strtotime ja date voisivat olla vain if-lauseen sisäpuolella ja ne voisi jopa korvata kokonaan merkkijonofunktioilla (kuten substr).

Jos sitten optimoinnin (eli turhien funktioiden poistamisen) jälkeen edelleen uskot, että foreach on ongelma, niin kyllähän sen voi korvata hienoilla taulukkofunktioilla. Taas lähdetään ihan alkeista, eli katso nyt kunnolla, mitä tietoa tuo foreach-silmukka edes käsittelee. Selvästi filtteröitävä tieto on worklogs eikä $phpNative.

$worklogs_filtered = array_filter($phpNative['worklogs'], function($value) {
	// Tänne if-lauseet ihan suoraan foreach-koodista
	if (blaa + blaa + blaa) {
		return true;
	}
	return false;
});

Tämän jälkeen joudut silti järjestelemään dataa uudestaan, jos haluat saman tuloksen kuin foreach-silmukasta:

$json['worklogs'] = array_map(
	function($value) {
		return [
			'id' => $value['id'],
			// jne.
		];
	},
	$worklogs_filtered
);

walkout_ [14.04.2022 23:15:20]

Metabolix kirjoitti:

(14.04.2022 17:26:27): Jostain syystä tuntuu, että olisi käsitelty...

Koodin pätkäsi eivät toimi sen nopeammin kuin minun, Hallutuksemme Pj ei vaan ole tyytyväinen ohjelman toiminnan nopeuteen, eikä se tiedä mitään Jira Cloudin ja Ext JS:n toiminnallisuudesta ja teknisistä rajoituksista, jne. (itse olen erimieltä) Ja hän on liian ahne hinnoittelussa ja menettiin tämän takia yksi hyvä potentiaalinen asiakas, kun itse lupasin 60 € / tunti + ALV 24 % ja sen asiakas hyväksyi ja Pj sano, että hinta on 100 € / tunti + ALV 24 % ja sitten asiakas irtisanoi sopimuksen. Mutta mikäs voin kun myin 0 € koko toimintani Pj:lle antaen hänelläe osakeenemmistön. PERKELE!

walkout_ [15.04.2022 06:30:04]

Metabolix: Sinun koodisi on kuitenkin hienommin tehty kuin minun tekemä vaikkasin se ei nopeuta asiaa, koska Appsini GUI tekee 7 erillistä lautausta jokaiselle viikkonpäivälle, koska viikonpäivät ovat erillisiä Ext JS Gridejä. Pj oli ehdottanut että sovellus tomisi nopeammin jos ensin data tallennettaisiin Jira Cloudista meidän palvelimen MySQL-tietokantaan ja taustaajona vietäisiin Jira Cloudin tietokantaan ja tuhottaisiin taustaajon jälkeen meidän tietokannasta ja Atlassian ei oikeen pidä tästä ajatuksesta mutta eivät kuitenkaan jyrkästi kiellä asiaa yksin oikeudella, joka takoittaa sitä, että meidän pitää antaa Atlassianille lisäselvitys miksi ja miten tämä ratkaisu on tietoturvallinen, jne.

Metabolix [15.04.2022 07:38:46]

Se on myös satavarmaa, että jos joka sivunlatauksella ennen tuota käsittelyä haetaan kaikki data Jira Cloud REST API:n kautta, niin pullonkaula on siinä hakemisessa ja sivun muulla koodilla on ehkä 1% merkitystä.

Itse asiassa siitähän täällä viimeksi puhuttiin, kun sinulla oli silmukka täynnä REST-kutsuja.

walkout_ kirjoitti:

Appsini GUI tekee 7 erillistä lautausta jokaiselle viikkonpäivälle, koska viikonpäivät ovat erillisiä Ext JS Gridejä.

No tämä varmaan kannattaa korjata, että olisi vain yksi lataus ja siinä kaikki data kerralla. Mahdollinen hyöty tästä on kuitenkin jo 7x, jos se päivämäärän mukaan filtteröinti tapahtuu noin PHP:llä.

walkout_ [15.04.2022 08:05:52]

Metabolix kirjoitti:

(15.04.2022 07:38:46): Se on myös satavarmaa, että jos joka...

Sitten minun pitää tehdä oma Ext JS -plugin, joka korvaa sen oletus-gridin.

carabia [15.04.2022 13:26:07]

Mutta onko sinulla sopivat Ext JS licenssit että voit tehdä plugareita? Tai oletko red hat entterprais edissöön licensoitu evankelista?

muuskanuikku [16.04.2022 07:20:03]

walkout_ kirjoitti:

(15.04.2022 06:30:04): Metabolix: Sinun koodisi on kuitenkin hienommin...

Kuulostaa ihan hevonpaskalta. Se data on teidän palvelimellanne siinä vaiheessa, kun se on ensin haettu HTTP-pyynnöllä. Tämän jälkeen tietoturvallisuus on Atlassianin osalta jo menetetty. Käyttöehdot voivat kieltää tietojen "pysyvän tallennuksen" mutta sitten teidän pitää riidellä siitä, mikä on pysyvää tallennusta ja mikä ei.

Joka tapauksessa muitakin vaihtoehtoja on. On olemassa puhtaasti RAM-muistissa toimivia tietokantoja, jotka eivät tallenna tietoja pysyvästi. Toinen vaihtoehto on myös käyttää PHP:n APCu-kirjastoa, jolla tiedot voi tallentaa PHP-prosessin muistiin (RAM:ssa) ilman että ne ovat levyllä missään saatavilla.

Grez [16.04.2022 09:22:27]

Selkeästi "pysyvä tallennus" on vastakohta "väliaikaiselle tallentamiselle", eli väliaikainen tallennus on ihan OK, vaikka levylle. (Levylle tallennuksessa toki pitää osata huolehtia siitä että se ei jää pysyväksi)

Metabolix [16.04.2022 09:25:44]

walkout_ kirjoitti:

Sitten minun pitää tehdä oma Ext JS -plugin, joka korvaa sen oletus-gridin.

Tai sitten lataa data kerralla ja syötä joka gridille erikseen. En ole käyttänyt kyseistä kirjastoa, mutta täytyyhän siinä olla keino syöttää muuta kuin suoraan pyynnöstä tullutta dataa kokonaisena. Googlella löytyy esim. ArrayStore, joka näyttäisi siltä, että voisi syöttää itse koottua dataa.

Palvelimen puolella helppo temppu olisi tallentaa tiedot vaikka istuntoon ensimmäisellä latauksella ja jakaa myöhemmin vain sieltä. Siinä on yleensä valmiina jokin poisto eli säilytys on väliaikaista.

walkout_ [16.04.2022 17:48:43]

carabia kirjoitti:

Mutta onko sinulla sopivat Ext JS licenssit että voit tehdä plugareita? Tai oletko red hat entterprais edissöön licensoitu evankelista?

Tottakai on. Ja lisenssiavaimet ovat täätällä mun koneella tallessa. Ja Shencha, Inc. tietää minusta tosihyvin joten mun ei kannata yrtitää varttaa etten joudu todelliseen kuseen. Ja ks. yrityksestä soitellaan kokoajan, että ostaisinko Ext JS 7:n kun mulla on se 4.2 vain ja siihen ostetu lisenssi.

Ja firmamme on Red Hat Technology Partner koska ne uskoo niin vankasti meidän sovelluskehitysalusta ideaan jolkka asiakkalle esennataan vain valmispohja ja aloitetaan softakehtysprojekti. Ja olenko saanut tälle asiakkaita no kyllä olen ja projektit ovat ikusuusprojekteja ja kokopäiväisiä sellaisia. Ja niin usko Canonical Ltd:kin joka valmistaa Ubuntua ja oltiin niiden Software Partner niin kauan kun ks. partner-ohjelma oli olemassa.

Ja olen tosikova neuvotteleen diilejä ulkomaalaisten yritysten kanssa, sellaisella kuviolla että rupeen niille ilmaiseksi myyjäksi sellaisella ja sellaisella idealla ja sitten ne pistää mulle jopa niiden 34600 USD maksavien softien lisenssit välittömästi tuleen hintaan 0 € UPS-paketissa postissa.

Sivun alkuun

Vastaus

Aihe on jo aika vanha, joten et voi enää vastata siihen.

Kirjautuminen

Haku

Tehtävät

Keskustelu: Ohjelmointikysymykset: REST kutsun response bodyn filteröinti ilman foreach looppia PHP:lla

walkout_ [14.04.2022 09:36:39]

Teuro [14.04.2022 10:18:46]

walkout_ [14.04.2022 10:29:01]

Teuro [14.04.2022 10:48:42]

walkout_ [14.04.2022 10:52:51]

Teuro [14.04.2022 10:56:56]

walkout_ [14.04.2022 11:02:28]

Teuro [14.04.2022 11:06:01]

walkout_ [14.04.2022 11:10:02]

Teuro [14.04.2022 11:28:50]

walkout_ [14.04.2022 12:00:42]

Teuro [14.04.2022 13:42:57]

walkout_ [14.04.2022 14:01:37]

Metabolix [14.04.2022 17:26:27]

walkout_ [14.04.2022 23:15:20]

walkout_ [15.04.2022 06:30:04]

Metabolix [15.04.2022 07:38:46]

walkout_ [15.04.2022 08:05:52]

carabia [15.04.2022 13:26:07]

muuskanuikku [16.04.2022 07:20:03]

Grez [16.04.2022 09:22:27]

Metabolix [16.04.2022 09:25:44]

walkout_ [16.04.2022 17:48:43]

Vastaus