Hi, guys,
I am thinking about the method-centric approach.
In earlier discussions, it was noted ( and i think agreed by most ) that
the steps to create a particular object could be arbitrarily complex. I
think the only method-centric format that will not result in loss of
generality will be python code. ( Unless of course the file is a wrapper
with some header information and a python code additionally ).
It would be conceivable to store objects as a python script that creates
the object without loss of generality, but I think there are several
challenges with this:
- Performance would become a problem in larger models. i think there
is a real need in cad systems for 'opaque' objects-- ones you can include
and interact with, but cannot afford to rebuild every time. Examples would
be an assembly with 1000 or so nuts and bolts
- Dependency management comes into play. since python is a programming
language that can import dependencies,a script to create an object might
import libraries unavailable on another platform, or might use a different
version of python, etc. If a python script is the serialization
format,these dependencies must be considered.
- the interface is not well defined. If a object is in a set format,
for example STEP, the format defines a very specific 'interface'. in the
case of step, a single step file contains a tree of entities that exist in a
well defined structure and notation. the format defines how to infer this
structure to learn what objects are in the file. A python script, though,
could produce an arbitrary number of objects in an arbitrary strcture, and
may not do it in a standard way. So, if a python script were used, it would
need to export well-defined functions that allow a caller to get this
information.
Most of these challenges can be solved. Interestingly, I believe that
following the 'module-based' will result in cad models handled much the same
way as programming projects are. You wouldnt need a new type of repository,
you could just use svn becuse you just need to store source code.
assemblies are just python projects that import a bunch of python libraries
from others ( which happen to produce objects ). The biggest challenges,
too will be those programming projects face-- namely, dependency
management.
I suspect we would end up needing to have a way for each 'module' to
describe not only what objects it exports, but also a way to enumerate its
dependencies both in terms of runtime ( eg python libraries and such ) as
well as other objects it is dependent on ( eg, others it has aggregated )
the apache maven project impements a very similar model for java code by
using a pom.xml file ( project object model) that allows a java project to
declare this type of information. Then, maven assembles the project by
automatically finding and resolving all of the dependencies ( including
transitive ones ) from repositories storing the dependencies
------------------------------
*From:* pythonocc-users-boun...@gna.org [mailto:
pythonocc-users-boun...@gna.org] *On Behalf Of *Thomas Paviot
*Sent:* Thursday, December 30, 2010 4:00 AM
*To:* jelleferi...@gmail.com; pythonOCC users mailing list.
*Subject:* Re: [Pythonocc-users] writing OCC data to a db
Hi Jelle,
Interesting topic, this going to be a long thread!
The use of a python ORM is also the choice I would have done. In my mind,
there are two ways to model such a database:
- a "data centric" db: you store the result of the different operations you
ran (for instance a Point and a Cube);
- a "method centric" db: you store the functions that you called and the
parameters passed (for instance "create_point, 10,10,10" and "make_cube,
20,30,40").
For the data centric method, the db size will be more important than the
second solution. For each object, I would only create a key and a "STRING"
field in which I would store the output of the serialization of the python
object (with the pickle module).
The second method require less size but more computing time (since the
different operations has to be computed each time you load the model).
I have the feeling that this discussion is very close to the thread related
to data model of the High Level API. That's something that could be an
additional constraint of the HLA: "All pythonOCC HLA objects must be
serializable to an XML file in order to be exchanged/shared through a
network or stored to a database".
Cheers,
Thomas
2010/12/29 jelle feringa<jelleferi...@gmail.com>
Hi,
Recently I had enough of storing OCC's cad as files.
Sometimes all you need is a database.
Turns out that its really easy to do so. Perhaps its worth sharing how
this can be done...
Though this might be pretty trivial technically speaking, it can open up
interesting ways of collaborating on projects.
-jelle
================================================
from OCC.Utils.Topology import Topo
__author__ = 'jdf'
from sqlalchemy import *
from sqlalchemy.ext.declarative import declarative_base
from sqlalchemy.orm import sessionmaker, scoped_session
from OCC.Utils.Construct import make_cube
#from OCC.TopoDS import TopoDS_Shape
#
#TopoDS_Shape.__eq__ = lambda x: TopoDS_Shape.IsEqual(x)
cube = make_cube(1,1,1)
engine = create_engine('sqlite:///jelle.db')
Base = declarative_base(bind=engine)
Session = scoped_session(sessionmaker(engine))
def comp_brep(brepA, brepB):
import ipdb; ipdb.set_trace()
print 'jajajaj',brepB, brepA
return brepA.IsEqual(brepB)
class Individual(Base):
'''used to store data about an individual
a row forms a generation
'''
__tablename__ = 'individual'
id = Column(Integer, primary_key=True)
#name = Column(String)
#fullname = Column(String)
#password = Column(String)
generation = Column(Integer)
ancestor_a = Column(PickleType())
ancestor_b = Column(PickleType())
brep = Column(PickleType(mutable=False)) #comparator=comp_brep)) #) )
fitness = Column(Float)
Base.metadata.create_all()
indy = Individual()
indy.ancestor_a = 'parent_a'
indy.fitness = 12.
indy.ancestor_b = 'parent_a'
indy.generation = 1
#indy.id = 0
indy.brep = cube
'''
to INSERT many rows very quickly, use the "executemany" style of
insertion:
connection.execute(table.insert(), [{'foo':'row1'}, {'foo':'row2'},
{'foo':'row3'}, ...])
'''
s = Session()
# s.begin()
s.add(indy)
s.commit()
s.close()
print('closed the previous db session\nlet\'s see if we can read back the
objects, that be cool...')
engine = create_engine('sqlite:///jelle.db', echo=True)
Base = declarative_base(bind=engine)
Session = scoped_session(sessionmaker(engine))
s = Session()
from OCC.BRep import BRep_Tool
bt = BRep_Tool().Pnt
for indy in s.query(Individual):
print indy.id
for i in Topo(indy.brep).vertices():
print bt(i).Coord()
================================================
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
