Hacktoberfest - task

issue - Currently all the errors raised by pysondb are in the same file where JsonStorage class is. This is not considered to be a good practice. So moving the errors to a different file (errors.py) will make the code base look more concise and beautiful.

Info

pyVersion: Python 3.10 OS: Windows 10

Describe the bug

Only the latest added entry can be found else this error accrued pysondb.errors.db_errors.IdNotFoundError: Id '184766099262345250' does not exist in the JSON db How to reproduce

GET Output

[
  {
    "id": 130978302791852290, 
    "name": "lol", 
    "state": true
  }, 
  {
    "id": 184766099262345253, 
    "name": "lol", 
    "state": true
  }, 
  {
    "id": 135312220569528861, 
    "name": "lol", 
    "state": true
  }
]

Used Code e.g. Delete Data by ID

        id = data["id"]
        database=db.getDb("data.json")
        #id =database.getBy({"id":id})
        database.deleteById(id)
        return id + " deleted"

If I delete the last one ID in this Out here 135312220569528861 this works fine but another IDs couln't be found. Expected behavior

Find the correct ID

Hi , im having this error when i try to import the db. so sorry im new here.

i have intalled this version: pysondb 1.5.6

(test_project_env) [root@test-01 test_testing-json.py]# python3 Python 3.6.8 (default, Nov 16 2020, 16:55:22) [GCC 4.8.5 20150623 (Red Hat 4.8.5-44)] on linux Type "help", "copyright", "credits" or "license" for more information.

from pysondb import db Traceback (most recent call last): File "", line 1, in File "/data/ftp_project_env/lib64/python3.6/site-packages/pysondb/db.py", line 74, in class JsonDatabase: File "/data/ftp_project_env/lib64/python3.6/site-packages/pysondb/db.py", line 234, in JsonDatabase self, key: str, _re: Union[str, re.Pattern] AttributeError: module 're' has no attribute 'Pattern'

Thanks for the awesome library but I am facing a small issue here I am using the library in Azure Databricks to write some logs but the library for some reason changing the log level for the cluster machines to be DEBUG so it makes it write to many logs like the image below so if you can provide a way to stop or change the log level it will be great

Edit: I believe the issue is here https://github.com/fredysomy/pysonDB/blob/29c1d363aac33c8c6e332d27e3043f52a7f54f60/pysondb/db.py#L12

Hey guys, if you like how pysondb works, and want other people to know about us, then write a blog post about using pysondb in you projects and your user experience and spread the word. One you have done it. Share the link here.

Let's take pysondb to the moon 🚀🚀🚀🚀

I got the idea for this issue from this post

How would this feature be useful? I'd like to contribute to this feature is it's valid. This command can be used to export an existing DB into CSV format.

Describe the solution you'd like A CLI command which takes in the name of the DB and the CSV file name to be exported into.

Describe alternatives you've considered Before proceeding, I wanted to know if this is a valid idea for implementation. Any other suggestions that can be used to implement this will be helpful.

Describe the bug When writing data to the JSON db, after the first write to the file, the .find() method will return the record based on the ID. After adding a 2nd record and trying again, the IdNotFoundError error is thrown despite the record being in the DB!

How to reproduce python 3.9.6

from pysondb import db

if __name__ == "__main__":
    db = db.getDb("test.json")
    while True:
        id = db.add({"dev": "test"})
        print(db.find(id))

Expected behavior The record should be returning as expected.

This is a neat library, great work!

How would this feature be useful? retrieving object by its id (primary key) in O(1) times instead of O(n) time.

Describe the solution you'd like

currently json file looks like --- { "data": [ { "id": 1, "k1": "v1" }, { "id": 2, "k2": "v2" }] }

it should looks like --- { "data": { "1": {"k1": "v1"}, "2": {"k2": "v2" } } }

now we can fetch single items by its key using db["1"] in O(1) time.

How would this feature be useful?

This feature can be useful in preventing the entry wrong type of values.

Describe the solution you'd like

Maybe, we can define a schema with the keys and the expected types .

db.set_schema({"name":str, "age":int, "email":str, "bio":Optional[str]})

Describe alternatives you've considered ¯_(ツ)_/¯

How would this feature be useful?

I feel versioning json files in Database is going a useful feature. I can see it useful for version data artifacts in form of JSON objects.

Describe the solution you'd like No ideas at the moment

Describe alternatives you've considered

• https://github.com/iterative/dvc

Describe the bug

$ pysondb convert a.csv a.json
Traceback (most recent call last):
  File "/usr/local/miniconda3/bin/pysondb", line 5, in <module>
    from pysondb.cli import main
  File "/usr/local/miniconda3/lib/python3.9/site-packages/pysondb/__init__.py", line 1, in <module>
    from .db import getDb
  File "/usr/local/miniconda3/lib/python3.9/site-packages/pysondb/db.py", line 11, in <module>
    from pysondb.errors.db_errors import IdNotFoundError
ModuleNotFoundError: No module named 'pysondb.errors'

The pysondb/errors folder does not get installed.

$ pip install pyjsondb=1.6.1
pip install pyjsondb==1.6.1
ERROR: Could not find a version that satisfies the requirement pyjsondb==1.6.1 (from versions: 0.0.1)
ERROR: No matching distribution found for pyjsondb==1.6.1

I noticed setup.cfg still refers to version = 1.6.0.

How to reproduce

Expected behavior

https://pysondb.github.io/pysonDB/update According to updateArray method example on this page is need to change name=Pyson-CLI for name= ArrayEntry >> # In the file.json the data is updated for all data where name=Pyson-CLI like:

>> from pysondb import db
>> a=db.getDb("file.json")
>> a.getBy({"name":"ArrayEntry"})
>> [{"name":"ArrayEntry", "epic_array":[0,1,2]}]
>> a.updateArray({"name":"ArrayEntry"},"epic_array",3)
>> a.getBy({"name":"ArrayEntry"})
>> # In the file.json the data is updated for all data where name=ArrayEntry
>> # We can verify it below.
>> [{"name": "ArrayEntry", "epic_array":[0,1,2,3]}]
>> a.updateArray({"name":"ArrayEntry"}, "epic_array", 4, 4)
>> a.getBy({"name":"ArrayEntry"})
>> [{"name": "ArrayEntry", "epic_array":[1,2,3,4]}

to the JSON file:file.json for this example, should add {"name":"ArrayEntry", "epic_array":[0,1,2]} or another fields for this db?

https://github.com/pysonDB/pysonDB/blob/4fad660bfb2465b8524fbe314d03b84b30abcb7c/pysondb/db.py#L274

Hello,

The param indent is missing on deleteById method. It should be:

self._get_dump_function()(db_data, db_file, indent=3, ensure_ascii=False)

in order to be consistent with other methods

Regards and thanks for the lib again :)

https://github.com/pysonDB/pysonDB/blob/630af1e030815a70985a2d07fcc58386df12abbb/pysondb/db.py#L251

Hello,

I think that the intention of this line was to be

"db_keys: " + ",".join(sorted(db_data["data"][0].keys())),

Thanks for the lib :)

Describe the bug I'm trying to update my json every 2 seconds but after couple updateing it will be broken.

This is the normal ending of my json file.

This is the broken json

This is the error code

How would this feature be useful?

I am using pysondb to develop an API that will drive a frontend that uses javascript. The javascript number type, which is the default datatype for parsing ints out of json, starts to lose precision around 2 digits shorter than the ids provided by pysondb (18 digits, I believe). Even though we know the issue, a quick fix on the frontend is evading us. Changing the length of the ids on the backend would immediately fix the problem on all frontends that use javascript.

Describe the solution you'd like

• Some configuration for a database object which allows the target length of the id to be set. I believe this would be a very minor change

Here is the relevant code in In db.py

   def _get_id(self) -> int:
        return int(str(uuid.uuid4().int)[:18])

• Alternatively, some configuration to return ids as strings instead of ints would also solve the problem. This wouldn't require the database to actually change its internal logic to use strings instead of ints, it would just require a (optional) casting function to be applied to any incoming or outgoing ids.

Describe alternatives you've considered

• We could handle casting from int to str ourselves. The problem with this is that id is used everywhere in the api code, and transitioning every data model class to use strings instead of ints would take a long time and introduce bugs.
• We briefly considered chopping off the last 2-3 digits of the id ourselves at creation time, but we can't figure out how to actually modify the id in the database entry without some insane hackery.