at the end of the transaction (the last
invalidation number will have been long forgotten by Zeo)
- it might slow down transaction to add an exchange at storage join (if there
is none at the moment, which I don't know)
--
Vincent Pelletier
___
F
o this, thanks a lot.
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
w who used that "undo" tab are actually interested in undoing
transactions modifying context, not transaction done on context (so they
actually want to use the efficient "history" tab, the one using FileStorage
object version back-pointers).
--
Vincent Pelletier
__
terprise-High.Performance.Zope/view
Regards,
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
ld help here, not sure if it's worth
the overhead.
Why not defining some kind of callbacks in Storage API, which would allow to
plug such mechanisms in a storage rather than wrapping around it ?
--
Vincent Pelletier
___
For more information
probably be disabled
by default before integration.
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
ve written about it earlier.
[1] http://zodb.org/documentation/articles/ZODB2.html
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
Le lundi 24 mai 2010 12:02:40, Wichert Akkerman a écrit :
> which prevents the exception overhead.
Right, thought this is a tradeoff question: writing as exception handling is
faster for "volatile is present" case, but slower for "volatile is missing"
case.
infer that
it is already standard for this to happen.
> As with NEO, zc.zodbdgc was motivated by multiple databases where a single
> database doesn't have enough information to perform garbage collection.
Thanks for pointing this package out, I didn't know it.
--
Vincent Pelle
lock at the end of the
> first phase. The lock is held while conflict resolution is
> performed.
Oops, I didn't realise that ZEO was postponing Storage.store calls until
tpc_vote call. I now realise that this is required to not interleave stores
from different tran
updated
version (esp. with the achieved/targetted isolation level).
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listi
ed by ZODB itself, especially for higher
level use-casess.
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
ng to fix in zope.publisher ? If so, I'll open a
bug.
[1]
http://svn.zope.org/zope.publisher/trunk/src/zope/publisher/publish.py?view=markup
Regards,
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zop
g.py?rev=113734&view=markup
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
n self.options.products + Products.__path__:
+if d not in L:
+L.append(d)
+Products.__path__[:] = L
self.setup_default_logging()
self.check_socket()
self.clear_socket()
--
Vincent Pelletier
___
F
was feeling late on this. I had a need for such option 4 years ago,
but didn't have the knowledge to implement it back then.
> Especially since there's an easy workaround like described above
Indeed.
Regards,
--
Vincent Pelletier
___
Fo
he rest
looks standard API to me (or at least, Connection-level API, not storage-
level).
...at least, we could get it to work in NEO ;) (easier than undo from
performance point of view, but that's another story).
--
Vincent Pelletier
___
For more inf
or packing) object
revisions are deleted
- garbage collection: unreachable objects are deleted
As you noticed, with FileStorage this actually happens by copying every kept
objects and transactions to a new data.fs, and swapping it with original
data.fs - which gets renamed as *.old.
Re
t class changed, the ghost will be of the
wrong class.
I think this bug was originally noticed by Julien (so CC'ed).
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
___
For more information about ZODB, see http://zodb.org/
ZOD
O
- FileStorage (would it still be inside ZODB ?)
- DemoStorage
- zlibstorage
- ...other Storage interface implementations (NEO, RelStorage, etc)
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing l
fix.
Jim: Beware, it's GPL'ed ;) .
/ducks
Regards,
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
yboard
- and a slow one, because it's late) and a pylint run.
Regards,
/me falls asleep on keyboard
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
ctually I'm not sure how this should be properly tested: testing this
requires reproducing race conditions, and I think one cannot reproduce all
possible race conditions in test cases, even knowing the code...
Ideas ?
Of course, I (as an exercise) stay focused on a stand-alone usage,
ries.
In current state my code should fit the needs of code outside transaction
management, such as zeo.memcache .
Regards,
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
___
For more information about ZODB, see http://zodb.o
Le vendredi 7 octobre 2011 15:02:44, Vincent Pelletier a écrit :
> Le vendredi 7 octobre 2011 14:16:42, Andreas Gabriel a écrit :
> > However, is your implementation thread safe? Maybe I am blind ;). That
> > was the reason I used lovely.memcached as memcached connector. Each
>
Le mercredi 12 octobre 2011 11:55:43, Vincent Pelletier a écrit :
> "distributed"
Woops. Networked lock server. Not distributed.
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
___
For more information about Z
None, so serial
was not set)
I verified there is no regression in "setup.py test", but I get 2 failures
(both with an without my changes), one on ZEO/tests/zeo-fan-out.test and
another on ZEO.tests.testZEO.client_has_newer_data_than_server .
Regards,
--
Vincent Pelletier
ERP5 - open s
ODB, that is.
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
are likely to alter the same object you will have poor performance, and
difficult decisions to take to get out of it (if constrained by backward
compatibility). When you must have a hot spot, design so that solving its
conflicts:
- is feasible (ie, there is one answer to enough conflict c
ough to solve the
issue wherever inter-database dependencies are one-way.
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
you will keep
the latest in commit order, not in transaction-begin order.
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
ht
starts: guess where in the object tree
that object is. If you have varied classes, and significant data on your
persistent instances, it will be easy.
Ragards,
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev ma
processing duration) might turn out
to be better, and also readily available with any ZODB back-end. If ran on a
big-enough (compared to available RAM and disk speed) ZODB, it will start
causing problems, though.
Regards,
--
Vincent Pelletier
__
is unsubscriptable
This is the actual error, which will go away if you provide a string.
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
have to have the code all over, and it won't be obviously
> separated.
Maybe a @property taking care of creating the actual PersistentDict if not
present, then ?
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.or
etstate__, and I've been bitten by it when
moving from Zope 2.8 to 2.12 (maybe 2.11 too ?) as 2.8 PythonScript objects
were modified on load on the new version (adding a trailing \n IIRC), which
broke "History" ZMI tab: one cannot alter a non-current object rev
org/gitweb/neoppod.git/blob/HEAD:/CHANGES
NEO is published on pypi as "neoppod":
http://pypi.python.org/pypi/neoppod
Regards,
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
___
For more information about ZODB, see http:/
On Mon, 27 Aug 2012 14:37:37 +0200,
Vincent Pelletier wrote :
> Under the hood, it relies on simple features of SQL databases
To make things maybe a bit clearer, from the feedback I get:
You can forget about SQL presence. NEO usage of SQL is as a relational
as a handful of python dicts
e general idea,
we don't have much experience with blob handling ourselves (which is
why we preferred to leave it asides rather than providing an
unrealistic - and hence unusable - implementation).
[1]http://git.erp5.org/gitweb/neoppod.git/blob/75d83690bd4a34cfe5ed83c949e4a32c7dec7c82:/neo/st
just modified objects. Otherwise, it needs to flush the whole cache.
I don't think there are other options on zeo side. I encourage you to read the
code to be sure (no need to read all of it, but there are helpful docs,
comments & docstrigns all over ZODB code). Check http://www.zodb.org
ootprint.
Any thought/comment ?
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
e committing to try to find points at which
databases are globally consistent. It does its job so far, but
beware: it won't resist malicious usage (trivial to DoS).
[1] https://pypi.python.org/pypi/Products.TIDStorage
--
Vincent Pelletier
ERP5 - open source ERP/CRM for fle
suits this better), but
at least to use (db_id, _p_oid) as a cache key.
--
Vincent Pelletier
___
For more information about ZODB, see http://zodb.org/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
t would be wondefull.
BTrees have a very nice API, which allow scanning only a subset of keys
by providing min and max boundaries:
for key, value in some_btree.items(
min='aa', max='b', excludemax=True):
# Do stuff
should do what you want.
http://pythonhosted.org/B
oups.com , and reply to
confirmation mail keeping subject intact. You should then receive
subscription confirmation.
--
Vincent Pelletier
ERP5 - open source ERP/CRM for flexible enterprises
___
For more information about ZODB, see http://zodb.org/
ZODB-De
all to TM._register "only" causes the instance to
be commited at next transaction using it.
Is there any reason why TM._register is hiding exceptions ?
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http:/
e bugtracker about this problem, because it's a
separate issue from the TM.py problem:
https://bugs.launchpad.net/bugs/229863
--
Vincent Pelletier
___
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
ion class inheritance scheme is not so
good, and that it would be needed to create more abstract exceptions classes
to inherit from. For example, an exception class which would instruct
publisher to retry transaction and another to instruct it to give up (
revented (they currently are when exception
happened during TPC).
I'm not sure about the case where exception was raised before TPC: should
commits be prevented in this case too ? Maybe it's the coder's responsibility
not to call commit in the error hook.
--
Vincent Pelletier
49 matches
Mail list logo
