yorik wrote: ↑Wed May 20, 2020 9:00 am
@onekk: In principle anything can be embedded in a FreeCAD file. That's why the file format is designed that way. But I also think a database is overkill to solve an internal problem, unless you specifically need a database, like GIS. I would find it totally sound to have a GIS workbench save a database file inside a FreeCAD file. But then that GIS WB is sole responsible for dependencies, libraries, and all it needs.
Yes, but someone has told that there will be problems fi there are many objects, why don't use the database interface, a carefully created database could hold thousands of annotations and permit complex queries, and maybe some other nice things, like updating reference, and maybe searching annotations with conditionals.
a simple query could be done even in python, but for a complex query in say 10.000 annotations, maybe even the C++ code is complex to develop: let me explain.
Code: Select all
import sqlite3 as sq3
import json
conn = sq3.connect('/home/carlo-arch/annotations.db')
c = conn.cursor()
def create_db():
"""Create table"""
c.execute("CREATE TABLE annotations (Id INTEGER PRIMARY KEY, name, content, position, style)")
conn.commit()
def populate():
cnt = 0
for idx in range (0,1000):
cnt += 1
name = "ann_" + str(idx)
content = "contenuto dell'annotazione {0}".format(name)
pos = json.dumps((idx, idx, idx))
style = "style_{0}".format(str(cnt))
c.execute("insert into annotations (name, content, position, style) values (?,?,?,?)", (name, content, pos, style) )
if cnt > 3:
cnt = 0
conn.commit()
def retrieve():
for row in conn.execute("SELECT * FROM annotations WHERE style LIKE 'style_1'"):
print(row[0], row[1], row[2], json.loads(row[3]), row[4])
#c.execute("DROP TABLE annotations")
#create_db()
#populate()
retrieve()
for testing you have to run create.db and modify the path of the database, in
conn = sq3.connect('/home/carlo-arch/annotations.db')
once you have created the table, feel free to modify the
populate() and then launch it, or decomment both create and populate, for the first run.
Now you have the database, of 1000 or 10000 or even 100000 annotation, the table is simple, a name, holding:
- Id as index that could be generated in a automated way due to the "PRIMARY KEY" value in the creation table
- name that could be a meaningful name and could be used as a descriptor
- content the content of the annotation, watever you want
- pos a field that hold a tuple that is serialized using json, so it could hold whatever you want, maybe directly a Vector, we could try
- style a reference to the style_name, the proper style definition could be put maybe in another table where style_name could be the primary key
now after having created those hundreds of annotations, yoiu could retrieve them using simply a query like:
.execute("SELECT * FROM annotations WHERE style LIKE 'style_1'"):
if you want search in a big project some other things, maybe the author in a collaborative environment, add a author field and you could sort using conditionals using the style and the author.
writing simply a string "SELECT * FROM annotation WHERE style LIKE 'style_1" AND author LIKE 'yorik'", and then simply iterate in the row objects of the returned query.
No need to write if then else or so.
yorik wrote: ↑Wed May 20, 2020 9:00 am
Let's start designing such a generic, multi-annotation (Draft) annotation! I think it is a very good path to go.
I think it should:
1) not be shape-based, as there is no need for shapes here (no booleans, etc)
2) contain "subobjects" like texts, dimensions, and generic geometry (that can yes be obtained from shapes)
3) have a very nice and well-designed task UI and toolbar. Maybe actually it should be an own workbench? Like sketcher? That is activated on edit?
4) coded in C++? I would find that pretty interesting for the speed, and if we start a separate WB, we can start from scratch really nicely. I did something very similar when we started coding Path, started with designed the "invisible" subobjects (Path command, path tool, etc...) then the FreeCAD docobject that holds them all, then the view provider, then the UI... I think it proved pretty solid
storing the important information of an annotation could even create them on the fly in the final document, if needed.
Not telling that a BLOB field in sqlkite coudl hold a 1MB binary data that maybe could contain directly the object if it serialized in some way.
Regards
Carlo D.