WEEK 7: ENTRY 2

 Today at my internship, I was tasked to create an elasticsearch query to generate different properties of a field. Elasticsearch is a Rest API search engine that makes searching for data very fast and straightforward. It involves using clusters and indexing to generate data. One can generate the data in two ways: by using the Elasticsearch CLI or writing an elasticsearch query. I chose to use the latter because I needed to write a Golang HTTPS request and pass that query in order to get the data that I specified in my query. Unlike how easy or rather simpler it was for me when I had to write the Big Query API query, it was a different experience today because elasticsearch query does not use SQL querying. It uses a DSL query, which simply refers to Domain Specific Language. The DAL is based on Json to define queries: key value pairing.


Apart from the fact that I had no prior experience with DSL queries, I also did not have any experience with the Elasticsearch API. Therefore, I spent some time reading about the different components that are on the Elasticsearch API. To my surprise, I learned that the API has a console, where I could write basic DSL queries and test out my understanding. So too, my manager sent me an Elasticsearch CLI command that I could replicate to a DSL query. This really helped me getting started with console practice. However, it deviated my attention and understanding on what other query methods I could use to generate the result I needed for my query. Instead of reading more about DSL queries, I spent ample time trying to replicate the CLI command that he sent me. I struggled to write it into a DSL query because that query was used for a different purpose. It mainly made use of the fields option sub-level from the data and not the _source option. Thus, I had to rely on my manager to pinpoint that to me, which I didn’t feel proud of myself. 



Overall, today was a mixed feeling of understanding the elasticsearch api tool Inwas using and realizing that it is very important to look at the bigger picture and not rely on references to resolve your issue. I gained the insight that references are meant to guide you closer to the solution and not exactly the solution. Thus, henceforth, I plan to use references as guidance and not replicating them to resolve my issues. So too, I intend to be more alert and proactive with my Google searches because it is one of the most important skills one must have. I learned that tailoring a google search brings you closer to the answer you’re looking for.

Comments

Post a Comment

Popular posts from this blog

WEEK 4: ENTRY 3

  Today at my internship, I was assigned the issue of troubleshooting why my GET request Golang code is unable to generate the data from my http server. Since it was a combination of k8s deployment and Golang go, it was trickier and harder than I envisioned. The k8s was mainly used to orchestrate the objects that are needed to generate keytab from my pods. After several debugging: comparing and contrast the referred file I used as a source code coupled with looking up the errors on Stack flow (suggested me to delete my deployment and redeployed), I was still unable to fix the issue. Partly was because I did not understand what the error message was pointing at. Thus, I had to consult a member of the k8s team, who figured out that my deployment.yaml file was missing some configurations that needed to generate my key-tab. Simply, I needed the key-tab in order to be able to make the HTTP Get Request get my desired data.   Although the recommended solution from my consultation wor...
Read more

WEEK 6: ENTRY 3

  At my internship today, I continued unmarshalling the Json data I got back from Big Query API. Having tried replicating the data on the Go playground and using the Go unmarshall function yesterday, I did develop a better understanding of the json structure. I used Go’s struct to do the unmarshalling. Unlike the json data I got from my query, the documentation’s json data does not have any schema metadata and so I thought the same approach would not work. Little did I know that the schema data can be ignored when unmarshalling json data and that you can only concentrate on the part of the Json you want to unmarshall. When I consulted my buddy, he hopped on a zoom call with me and we did pair programming. I was the driver while he was the navigator, basically explaining what we were doing because he has more knowledge on Go and Json data manipulation. Working with him gave me more skills and confidence in what I was doing. He helped in not just using the Go struct, but also in tryi...
Read more

WEEK 7: ENTRY 1

  It sometimes feels like we are not good enough when our tries don’t work. Well at my internship today, I worked on resolving the json unmarshalling issue I was stuck with last Friday. After several back-and-forth consultations with my buddy and manager, I finally got a better understanding of how they wanted me to present the data. Basically, the data should be in a simple json array that could be manipulated easier. This is because as the json comes in key:pair format, I would need to extract all the keys and use those keys to send an HTTPS request to Elasticsearch Rest API.  Even though the approach was well defined and clear to me, I still struggled to implement it using the Golang Struct and Maps. One of the obstacles I had was because after unmarshalling the json data, the output was in a Golang interface type, which was not iterable like say a slice. A Golang slice is the equivalent  of a python array. Therefore, to overcome that barrier, I created an empty slice ...
Read more