I works now (sort of) but i still have the issue (sort of)..

In the version that works, I create a one time reference obj, then use
it by running through its dict structure. This can be pickled and put
into a table with the older DAL, but not with the new:

               dfo_objCmd =
self.dfo_builder.dictOjectFunctionWrapper(cmdDFO)


Now, I tried something different. I use the same same object, but set
a new root (like setting a new root from an existing xml object). This
can be pickled and put into a table... I don't know why this works,
but it does.

            ...cmd

            for item in self.dfo_builder.build.cmd_init_:
                if item.cmdName == cmd :
                    dfo_objCmd = item.cmdName


So, turns out, I need to apologies for pointing the finger @ DAL...
This has to be something on my side. So, apologies for the ruckus and
for not looking deeper into this sooner.

And thanks for taking the time

Mart :)








On Jan 15, 10:16 pm, mart <msenecal...@gmail.com> wrote:
> 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(_cumulativePropertie 
> s))
>
> 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.e 
> tree_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.e 
> tree_builder))
>
> self.db(self.db.buildData.id==id).update(etree_main=cPickle.dumps(etree_mai 
> n))
>         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