DEV Community: marknosal

Association Creator Method

marknosal — Sun, 21 Jan 2024 01:48:23 +0000

Intro

SQLAlchemy is an Object Relational Mapper (ORM) used as a link between Python objects and database records. Since Python is Object Oriented and databases are relational it allows Python code to be easily converted to SQL. This in turn makes the interaction between the two realms seamless. Since it uses a Pythonic syntax, developers can write database queries in code they are familiar with.

Association Proxy

With some experience in coding models in SQLAlchemy you'll have noticed relationships between them can become very intricate very quickly, escpecially in a many2many relationship. The association proxy is a wonderful toolthat was developed to simplify the complexity by untangling the extra steps you have to go through to create a many2many relationship. The proxy's come in handy also allows for easier management of attributes and code readability, but its helpfulness in many2many relationships is where you'll most likely see its advantage.
Here is an example of crating a many2many without utilizing the association proxy. One way requires you to create a seperate association table to link the two models:

Here is the same many2many relationship, but utilizing SQLAlchemy's association proxy instead:

As you can see the association proxy creates a more readable and concise way to link your many2many relationship. You can use in many ways such as linking a user to items through the user's cart (association proxy).

The Creator Method

Once you have gotten familiar with the association proxy you can learn about another one of its many uses, the creator method. It is a pivotal feature of the proxy that brings another dimension to your relationship mangement needs. It really shines where relationships need to dynamivally created during your application's runtime. The association proxy first takes the relationship the model is connected too, then it takes the attribute of the connected model that is connected to the other side of the many2many, the last bit is the creator argument. The creator argument takes instructions for how to create the instance of the intermediary model. Typically this is a lambda function.
Here is another example when Many book readers can own the same book and many books have many bookreaders through the book reader's bookshelves:

Here you can see when you add an instance of a model's relationship to their association proxy it will create a new instance of the connecting model (in this case a bookshelf) with the corresponding foreign keys.

Summary

We learned that SQLAlchemy plays a huge role as an Object Relational Mapper in Python application development. It helps smooth the interactions between developer's Python objects and their relational databases. Further we were shown one of its tools, the association proxy, that helps simplify complex many2many relationships in an elegant way. Lastly we explored the association proxy's creator method. Which helped in showing us a new way to create create and manage our database records and python object instances that link them.

Multi-Async Requests in One Submit Handler

marknosal — Sun, 05 Nov 2023 15:53:28 +0000

The more I coded the more in depth my applications became. As they grew in complexity I had a problem caused by an action by a user needing to alter more than one database record. It seemed straightforward at first, but I realized this may become an issue as the application scales. What if one request to the api completes, but another fails? The application needs to be efficient and as concurrent as possible when it comes to handling requests from the user. I found the Promise.all() method to be the best way to create an all or nothing way for sending my fetch requests.

Because of how applications can develop and grow almost exponentially, handling multiple API requests will be necessary. The issue doesn't get better because the more complex your application becomes, the more likely you will find yourself needing multiple requests to complete one user action. Lots of data in an application relies on other data so more concurrent you can get requests the better. The less concurrent they are the more likely a computer is to misprocess the code and give you an undesired response.

This is where I found value in the Promise.all method. The method will take an iterable (ex. list or array of fetch requests) and will perform them all. It will only execute the following code (ex. then statements) after all the requests get handled successfully. It will send multiple promises and only go to the next code once they have all been met. This works very well for asynchronous requests. Especially if they need to be performed together or when they all need to be completed or none at all. Here is a basic example:

In this example the onSubmit is given an array of 2 fetch requests with both sent to different routes. Each end with a then statement converting the response to json. If both both back successfully an array is returned with each index corresponding to the index of the original array of requests. In this example I named them according to the data the represented. Then final then statement takes that array of data and sends to various functions that control state. In this case it updates a client and a user, as well as minimizing the expanded client. If both or one of the requests failed it would be caught it the final catch statement and set the error to be displayed.

I use a custom Error component that will take an error (that is set in state). I put that component strategically in various components the user would be viewing so they can see the result right in front of them.

The use of all concurrent requests being handled successfully is important. Using my case for an example the two fetch requests sent are used to:

Lower the client's debt
Increase the user's earnings

You can see that if only one of the requests came back successfully and not the other would be detrimental to the data's integrity. If the request made to the client was successful, but not the user then the client's records would show that they owe less than what they actually do and the user never got paid accurately. Or in reverse, the user would have a record of being paid, but the client would show that they still owe the full balance. Instead of corrupting the data it will catch an error if either of the promises doesn't complete.

This can be very useful the more complex your code becomes. Especially when they one request interacts with multiple routes or tables in your database.

Hopefully this will help you manage multiple asynchronous requests in your future applications and help them to appear more concurrently.

"ValueError: Attempted Relative Import Beyond Top-Level Package" in Python

marknosal — Fri, 04 Aug 2023 17:14:39 +0000

When working with Python, I came across an error message that says "ValueError: attempted relative import beyond top-level package." This error puzzled me for hours so I assumed it would give issue to other developers. Having just created a CLI for a project (link at bottom) this error held me up for a while. In this blog we'll check out what this error means, why it occurs, and (hopefully) how to prevent it.

Understanding the Error

The error message "ValueError: attempted relative import beyond top-level package" happens when your relative imports attempt to go beyond the top-level in your project's directory structure. Python's import system is designed with modular programming and reusability, but there are rules and syntax that must be followed to ensure the desired import behavior.

Causes of the Error

Incorrect Relative Imports: Relative imports are used to import modules from the same package/subpackages. Performing a relative import that goes "above" the top-level package, your interpreter won't be able to locate the file your trying to specify.
Inconsistent Module Structure: This is more of a recommendation, but if the way you save your directories/files in your project in unorganized, the more likely issues will arise when trying to utilize relative imports.

Example Scenario

Here's a super basic file structure for a made up project:

my_project/
|----cli.py
|----subpackage1/
|----|----database.py
|----subpackage2/
|----|----other_code.py

If you try to use a relative import coming from other_code.py file like 'from ..subpackage1.database import session' you'll encounter the "ValueError: attempted relative import beyond top-level package" error. The interpreter is going from the cli.py file which is already at the "top-leve"

Solution

Absolute Imports: Instead of relative, use absolute! This will ensure they are being imported from the correct location.. For example:
'from subpackage1.database import session'.
Run Scripts Properly: This goes without saying, but if your running a script from the command line, make sure the directory your in is the root directory of your project. This can help Python locate modules correctly. I only ran the cli.py file in my project and it was in the top most directory.

Conclusion

Database Session Management: This snippet was used to avoid multiple database connections:

With this it used the absolute path to my database connection. That way I could import the session object into any file in my project without the system creating a blank 'phase3_database.db' file in the topmost directory every time I ran my cli.py file. It gave the python interpreter the absolute path to the to session object. If the python interpreter was running a file that was deeper in the structure than the cli.py file it used the absolute path instead of the relative path. I also structured my project file tree to all stem from where cli.py was located so I could use absolute imports. That made sure I never ran into this error again.

I hope this helps you avoid the "ValueError: Attempted Relative Import Beyond Top-Level Package" error. Especially when using SQLAlchemy with your own database.

Link to github project

Fetch Requests with Javascript

marknosal — Mon, 17 Apr 2023 22:18:52 +0000

0. Intro

Fetch requests are an important skill to master because it will make any full stake application you write able to save, read, edit, and delete data. Your application's ability to communicate with servers (or your server) is paramount. They are pretty simple once you see a few examples, but there are things you need to be wary about, such as their asynchronous nature.

1. Basics of the Fetch

At the base of fetch requests is the ability to standardize the way your web applications make/receive HTTP requests to/from servers. Its a line of communication from the client-side (ex. your browser) and the server-side (ex. Facebook's data centers). Some key components are:
A)URL or Uniform Resource Locator which specifies the location or server's endpoint where the data your trying to interact with is located.
B)(HTTP) Method this what I like to call a computer verb. It's what the computer is supposed to do with the fetch request. The most common you'll run into are GET(retrieving data), PATCH(updating existing data), POST(creating new data), and DELETE(removing data). There are other's but I won't get into them here.
C)Headers are used to describe additional info about your fetch request. They are used to help the server know what types of data to expect, credentials of the request's origination, etc/
D)Body, this is only for non GET requests. It contains data that is sent to the server. Useful if you are creating a new data record (uploading a picture, creating a username, etc)
Super Vanilla Example:

This is the most basic example of a fetch request I could think of, it only includes the URL. By default this making a GET request. It is asking only to retrieve the data located at the URL. It then converts the servers response to JSON, and finally console logs the data for you to see in the DOM or (if something went wrong) console logs the error.

2. Implementing Fetch Requests

I'll go over some examples of using fetch in a React component each of the other HTTP methods I listed (POST, PATCH, DELETE). All will be as vanilla as possible, but they'll be taken from code I've already written so they'll have real world functionality and not just used for examples (like Super Vanilla)

A)POST

Here you'll see the fetch is made to '/customs'. You'll see the method is POST because I'm sending data to the backend that I want the server to save or commit to moemory. Headers is the next few lines. The first is Accept, which lets the server know the data type the client (my DOM) can handle/is expecting(in this case, JSON). The Content-Type is the reverse. It's letting the server know that the data I'm sending is in JSON format. The body is the last part of the fetch request is the body. In this specific case I'm sending a key/value that I want saved in the server. JSON.stringify is used to convert a Javascript object or value into a JSON string representation. Its used to be stored as a string. JSON is useful because it is extremely lightweight and easy for humans to read.
That's it for the response. After that, in the then statements, the front end code is converting the servers response to json and then either logging the data if it was a successful request or logging the error to help me debug the code.

B)PATCH

Here's an example of a PATCH request. It works VERY similar to a POST, but I've sent it to a more specific endpoint in '/customs'. Its used for editting already existing data. In this case I have the id for the 'custom' record I'm trying to update. 'values' represents a prop that was passed into the submit function which this fetch request is contained in. In this specific case it is key/value of the specific custom's notes attribute ({'notes':'some note'}). If successful it will save the custom.notes to the value that is being sent. It can be used to dynamically update any custom's note attribute to a new value.

C)DELETE

This is the second easiest method besides GET. headers are not required and neither is a body, or handling a response for that matter (unless you coded it that way). You could send it to a specific record like I did for the PATCH and it would permanently delete the record located there. But for my specific case, I have it used to remove the current 'user_id' from the session aka logging out the current user.

3. Summary

To conclude, making fetch requess is a necessity for dynamic full stack applications. Some things that make them important are:
A)The standard communications between your laptop and the servers your applications communicate with
B)The asynchronous nature is allows your applications to flow smoothly and not be held up on a long loading screen while your waiting for your photos/data to load.
C)Since they return responses(or rather a promise that results in a response) it allows the engineer to handle the logic flow.
D)It can allow you to catch and handle errors in a specific or umbrella manner

Good luck!

Sales To Software: How I Got Here

marknosal — Mon, 13 Mar 2023 21:13:41 +0000

Beginning
It's still a little strange when I look at the path I took to getting into Software Engineering at FlatIron. I graduated with an Environmental Science Degree from Stephen F Austin in 2015. My first job was as a consulting utility forester for an electrical company on the east coast (half the country away from where I graduated). I wasn't making the money I wanted there so I did a complete career switch and moved back to Texas at the beginning of 2020 to try my hand in sales.

Transition
I did this for almost 3 years, but eventually I started to suffer from sever burnout. It was not fulfilling and amount of hours and stress wasn't worth the income. With some introspection I realized sales was not sustainable and no matter what dollar amount I made I would never love talking to people all day everyday. I liked using my mind to solve puzzles rather than using it to convince other people to buy things that I wouldn't even but myself.

My sister had gone through a very similar thought process more than a year before I did and I spoke to her extensively before making the switch. She had decided to change from sales to software engineering and had chosen FlatIron School as her starting point. She had already graduated and got a new coding job which she loved. Over a few months I always asked her how it was going and how she liked her new company. Her answer was always the same. She loved her company and she continued to love what she was doing. Since she continued to enjoy her job, I took it that her career switch as not just in the "honeymoon" phase.

Her path in conjunction with my own burnout was the reason I decided to switch. My wife and I were to due for a newborn at the beginning of February and I was lucky to have a job that offered extensive paid paternity leave. My upcoming child was the spark to sign up for FlatIron. I started at the beginning of January 2023 and have been loving it since then!

So Far
My career switch to software engineering is much better than being on call for an unfulfilling sales job All.Day.Every.Day. It scratches an itch I didn't even know I had and I love it. I'm only about 20% of the way through the curriculum (at the end of phase 1), but I've learned a lot more than I thought I would with the amount of time I've invested into this career path.

I've learned the basics of Javascript, HTML, and CSS. It feels like a lot, but I know I've just barely scratched the surface. To make an analogy to constructing a house:

HTML is like building the foundation and frame of the home.

CSS is creating the aesthetic of your home (color of the walls, species of landscape plants, construction materials).

Finally, Javascript is creating the functionality of the home and how it "does what it does". It's what makes the facet turn on, the toilet flush, or the AC cool your house.

Getting Laid Off
About five weeks into my paternity leave and the FlatIron curriculum my company terminated almost half of the sales positions they had. This was both negative and a positive. Although the latter vastly outweighed the former. I had never lost a job in my life before so I was concerned on how that would look on my resume and how to secure income in the future. Fortunately my old company took care of all their ex-employees they were letting go. They allowed me to finish my paternity leave and gave me a substantial severance package.

This was a blessing for me and my family. Not only will I be able to spend more time growing with my first newborn. I will have plenty of time to complete the FlatIron program AND secure a new job in the software engineering field. I was worried before because I would have to finish the program and get a new job while working at my overly stressful and demanding old sales position. Almost all the stress has been lifted. I'm not a religious person, but this definitely felt like a sign that I am currently on the right path.

Future with FlatIron
I'm looking forward with the next phases of the FlatIron curriculum. From the syllabus, we will be learning React, Python, and developing a better understanding of the full stack experience.

This is the first of seven blog posts I will be writing for the curriculum. They will be a little more indepth and technical than the intro I just wrote. There are a some topics that peaked my interest I would like to explore. The first being Undeclared Variables. I'm not 100% how they work, but my first experience with them was in the prework. The code I wrote was executing just fine, but I was certain it was supposed to give me and error because I hadn't used const, let, or var for a variable in my code. That lead me into a rabbit hole of the undeclared variables. Hopefully I'll be able to explore those in my next blog post, but no promises as they seem pretty deep.

Until next time...