In both versions, the following DAL activity is identical. But is
failing with the new DAL (the 1st was with sql.py, the 2nd with the
new dal.py. I just realized while copying and pasting that you have
the full file (was attached in an email and called "_blue.py"). The 2
type of objects that are failing are xml etree and dfo (dfo is like
storage but starts by converting etree to dict object and the other
way around). the dfo.py file has not changed in over a year. There a
huge difference between the file I sent you and today but not the
chunk of code below. all those objects are derived from an xml file
which which triggers a build when submitted. They all do their jobs
while the process is running, but the automation can't insert/update
to the DB with those lines of code below.

I could send more modules if it can shed light. Oh, and one last
thing, the web isn't part of this process. Strictly script which uses
dal + some gluon modules. the web comes after the build. And its at
that time that those objects get used the most (I.e. QA finds the
reports they want by doing (//
reportsServer.root.folderStructure.reports.aReportFile.html)

Anyways, if you have any thoughts, it would be great.

Thanks for taking a look :)


        dfo_main =
self.dfo_builder.dictOjectFunctionWrapper(self.dfo_builder.build._main_)
        etree_main = self.convert2EtreeByTagName('_main_')

        id =
self.db.buildData.insert(cumulativeProps=cPickle.dumps(_cumulativeProperties))
 
self.db(self.db.buildData.id==id).update(dfo_builder=cPickle.dumps(self.dfo_builder))
 
self.db(self.db.buildData.id==id).update(dfo_builtIn=cPickle.dumps(self.dfo_builtIn))
 
self.db(self.db.buildData.id==id).update(dfo_main=cPickle.dumps(dfo_main))
 
self.db(self.db.buildData.id==id).update(etree_builtIn=cPickle.dumps(self.etree_builtIn))
 
self.db(self.db.buildData.id==id).update(etree_builder=self.etree_builder)
 
self.db(self.db.buildData.id==id).update(etree_main=etree_main)
 
self.db(self.db.buildData.id==id).update(etree_builder=cPickle.dumps(self.etree_builder))
 
self.db(self.db.buildData.id==id).update(etree_main=cPickle.dumps(etree_main))
        self.db.commit()

On Jan 15, 5:28 pm, Massimo Di Pierro <massimo.dipie...@gmail.com>
wrote:
> I do not think anything has changed in this respect. Can you provide
> an example of doe that worked and does not work anymore?
>
> Massimo
>
> On Jan 15, 3:29 pm, mart <msenecal...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > seems I used to be able to store pickles, and now ... well I can't...
> > Has the API changed or have we decided to against the practice (which
> > generally I may agree with) but...  I need those pickles in there  for
> > archive purposes, reproducibility and necessary references to them...
> > I store run time data into dict objects (like storage) which are built
> > up throughout build process (they are not static).
>
> > Anyways, there didn't seem to be any issues a short while ago (pre-
> > updated DAL), but now I get these infamous exceptions;
>
> >                    .../dal.py", line 3431, in __getattr__
> >     return dict.__getitem__(self,key)
> > KeyError: '__getstate__'
>
> > thanks,
> > Mart :)

Reply via email to