Put individual table methods into their respective classes

[ankitchiplunkar]

Is your feature request related to a problem? Please describe.
The table methods are currently situated in the api.py file, this makes it not lean.

Describe the solution you'd like
There are two possible options:

1. Import classes from ether_sql library, then connecting these classes to their respective tables in the current psql. To add more methods we can inherit the class from ether_sql and add methods in them.

from ether_sql.models import Blocks

class ApiBlocks(Blocks):
    connect_to_table('blocks')

    @classmethod
    def current_blockNumber():
        logic_of_method 

2. The second option is not relying on ether_sql library but connecting to the table as implemented in

   ether-api/api/api.py

   Line 29 in 6268ef1

   Blocks=ss.get_table_object('blocks')

   and implementing the methods on this class directly.

I would prefer option 1 since, we can then reuse the ether_sqlfunctions as well.

[SaranshVatsa]

The way I implemented it the way it is right now is so that there is independence between the API and the library. The library models may be edited later (like you have to add the "index" column in Uncles) and the API won't be affected as it will query and serve data from the resulting database only. Since we are not adding more data to the database using the API (it's only GET, no POST links), we don't really need most of the predefined functions in the library's model classes. I had looked through them and only the "find_max_block_number" function of the library is of use to the API. As all other methods are to add blocks or transactions or uncles or to check for missing blocks, etc.
There are no functions to get transactions or blocks by their hashes, numbers, etc that we need in the API, so we'll need to rewrite them here again anyway. So I decided to just connect it to the tables and query them.

But yeah, if you think that in the long run the 1st option approach will be better, then we can definitely shift to that. It's your call, I am fine with either way, if you wanna follow the first approach I'll start looking into it.

[ankitchiplunkar]

I would prefer to have a single table class which contains most of the necessary methods, in this manner, we would save ourselves from doubling a lot of code and eventually let other people reuse the table classes with lots of implemented methods.

There are no functions to get transactions or blocks by their hashes, numbers, etc that we need in the API, so we'll need to rewrite them here again anyway

True for the current scenario this seems the most appropriate approach.

if you wanna follow the first approach I'll start looking into it.

Just have a look at how it can be implemented.

[SaranshVatsa]

So do you mean I should create another branch and try implementing the 1st approach on that?

[ankitchiplunkar]

Yes, try to implement it, if we like it then we can use the first approach.

[SaranshVatsa]

Trying to reply to your comment on the commit shows "pending", it's not getting sent to you.
I looked into it, and it seems that to follow that approach, by making a query to the database directly using the imported model class objects of ether_sql, we need to have an active ether_sql session, as only then the ether_sql model object will be able to access its function and make queries accordingly.
Yeah I agree that making a sub-class like we are doing right now is not really proving that beneficial, but yeah it is organizing the code better and into different modules.

Do you suggest we do something about this or should be just let it be? Because it's not really making that much of a difference anyway as the database is the same.

[ankitchiplunkar]

I have merged this PR you can start working on CI

…

On Wed 26 Sep, 2018, 16:48 Saransh Vatsa, ***@***.***> wrote: Trying to reply to your comment on the commit shows "pending", it's not getting sent to you. I looked into it, and it seems that to follow that approach, by making a query to the database directly using the imported model class objects of ether_sql, we need to have an active ether_sql session, as only then the ether_sql model object will be able to access its function and make queries accordingly. Yeah I agree that making a sub-class like we are doing right now is not really proving that beneficial, but yeah it is organizing the code better and into different modules. Do you suggest we do something about this or should be just let it be? Because it's not really making that much of a difference anyway as the database is the same. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#12 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFoaDmxgCbG2SWNO4YXfBkrvJj9p1pX9ks5ue5PAgaJpZM4WznFq> .