OracleStorage? Re: [Zope-dev] DCOracle2 Beta 3

2001-06-12 Thread John D . Heintz

Are there any plans to port OracleStorage over to use DCOracle2?

John


On Tuesday 12 June 2001 10:46, Matthew T. Kromer wrote:
 For all of you (or at least, BOTH of yousmirk) Oracle users out there,
 I packed up DCOracle2 Beta 3 this morning, including Z Oracle Stored
 Procedures as part of ZOracleDA.

 It can be found in the usual place,

 http://www.zope.org/Members/matt/dco2

 This isn't much different from Beta 2 except for some SP tweaks and the
 Z Oracle Stored Procedures, except that the NT builds are release
 versions with Oracle 8i (e.g. SP discovery code) features enabled --
 when I built Beta 2 I goofed the build and packaged a debug release
 without the 8i specific features on.

 I'll confess that I'm not a heavy user of Stored Procedures, so your
 mileage may vary; particulary when using IN/OUT binds where type
 conversions need to take place from unweildy Oracle native types (like
 SQLT_NUM.)

 If you play with the stored procedure objects in Zope, it's probably
 worth pointing out that the default permissions won't include execute
 permission -- you have to specifically enable that for non-manager roles.

 On the far-out front, a few people have asked how you might do
 user-specific connections to the database (ie instead of pooling by a
 common connection, you individually authenticate to Oracle with your own
 password).  Clearly, cloning the base Connection object would be fairly
 straighforward, but authenticating it to Oracle would not be, as the
 user password wouldn't be available.  If anyone feels strongly about
 that (ie you have a notion on how you would make it work and/or you need
 it), feel free to write me.  From a performance standpoint it would be
 terrible, but security auditors would love it.


 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Bulletproof ZCatalog proposal

2001-06-07 Thread John D . Heintz

Me too! Me too!

John

On Thursday 07 June 2001 08:49, Chris Withers wrote:
 Shane Hathaway wrote:
  But I think I have a solution for all of the issues in conflict
  resolution.  If you, or anyone else, is also interested in this, please
  show support (if only by saying please do this!) :-)  I can't work on
  it unless I have a reason to.

 Please do this! :-)

 I'm particularly interested in ZCatalog becoming a standard ZODB feature,
 and I know there are otehrs on ZODB-dev who are dying for this right now...

 cheers,

 Chris

 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] another Zope hanging..

2001-05-20 Thread John D. Heintz

I've added a patch to Python 2.1 on sourceforge that helped me considerably 
when diagnosing multi-threaded Python lock ups.  See 
http://sourceforge.net/tracker/index.php?func=detailaid=421709group_id=5470atid=305470
 
for the submitted patch.

I created this to give me at least as much functionality as Java has to dump 
the stack trace of all Java threads and Java monitors.

For an example of how I used it see 
http://lists.zope.org/pipermail/zodb-dev/2001-May/000703.html in the ZODB dev 
list.

Hope this helps,

John


On Friday 18 May 2001 09:13, Christian Scholz wrote:
 Hi!

 Just FYI: The server still hangs once a day and another one is doing
 the same..
 It even does this when simply accessing one page or image over and over
 again.
 More precisely I've started the server and did

 ab -n 10 -c 10 http://foo.bar/we/pics/someimg.gif

 (ab being the apache benchmarking utility)

 and after a while I get the broken pipe error.

 I've also changed my python version to 2.0 and tested it with this
 but still the same effect. Also changing the server (and thus
 hardware and system) did not help it.
 I've also removed the mysqlda from the zope installation but also this
 did not help..
 I will try now to create the smallest version of the site that still
 hangs..

 Dunno if anybody has some idea, I actually have none..

 I'll keep you informed..

 -- christian

 PS: strangely it works on the development server but also here I am doing
 some tests with ab right now.. and this one is still 1.5.2

 On Thu, May 03, 2001 at 02:16:30PM -0400, Chris McDonough wrote:
   Well, my problem might be that in my case most sql statement are done
 
  inside
 
   some attribute provider of ZPatterns.. This is using ZSQL methods
 
  internally
 
   but actually those then won't show up I guess..
 
  Even if you weren't using ZPatterns, the error probably wouldn't jump out
  and say here I am!  So I don't think there's much difference between
  using ZPatterns and not using ZPatterns.  The process of detecting when
  something hangs is just like any other troubleshooting process, it's a
  matter of exclusion.  If you notice that the request named
  foobargorf/fleafang *always* hangs, you investigate what it does, and
  try to reproduce it.  If it's incidental, so be it, and move on to the
  next theory.
 
   I've also seen that some more recent version of the mysql stuff is
   around and I am using this now..
  
   The problem's also that I just have a few methods to invoke from the
 
  outside
 
   which do lots of things by calling other object. Thus I might not
   really
 
  see
 
   what's really causing the problem.. I hope though that my upgrade will
 
  show some
 
   benefit..
 
  The -M log perhaps won't show you the actual operation that's causing the
  hang, but it will show you the entry point into a routine which causes
  the hang.  It's your job from there to track down the cause.  This is
  just like debugging a program.  You get an error somewhere, and you need
  to track it back to its root, which may be six levels up the call stack
  buried in some godforsaken regex.  ;-)

-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Experiments with ORMapping

2001-05-14 Thread John D. Heintz

I think this is a great idea!  I would definetely like to use and contribute 
to this effort.  Having this kind of flexibily would be fantastic.

After demonstratable Python code is working I would request that usability 
issues (UI Schema mapper, data migration/schema evolution tools, ZEO 
integration, multi-Storage uses) be addressed sooner than later.  

John

On Monday 14 May 2001 10:47, Shane Hathaway wrote:
 Chris Withers wrote:
  Shane Hathaway wrote:
   I'm telling you there's a lot more you can do with the code that makes
 
  snip
 
   The next thing to do is to write a fishbowl proposal.
 
  This sounds cool but made my head hurt :-S
 
  Can you try and bring this back down to the level of us mere mortals by
  explaining how your OR stuff would let me take a table of data in an
  RDBMS table and have it appear as objects in the Management Inteferace?

 Sorry, this is at a pretty low level and I do need to explain it better.

 One would define an ObjectMappingSchema whose job it is to store and
 retrieve objects of a specific type and in a specific location.  It
 would usually grab a database connection object to do its work.  When
 loading, it would perform a query then manually put attributes into a
 persistent object.  When storing, it would grab specific attributes from
 the persistent object and execute a statement to store those attributes.

 So let's say you want a ZODB to store and retrieve users in a specific
 table while putting everything else in pickles.  You would create an
 instance of PickleSchema, which implements the ObjectMappingSchema
 interface, and tell it to manage everything *except* the users mapping
 in BasicUserFolder objects.  You would tell it to store and retrieve
 this object using your UserFolderSchema instead.  Your UserFolderSchema
 would store and retrieve the users from the USERS and USER_PREFS
 tables.  The user table wouldn't require the use of OIDs but would
 require unique user IDs.

 So in the management interface nothing would change.  Nor would the
 application-level Python code.  You would only define a layer that maps
 objects to a relational database.  You would still see the user folder
 as you do now.

 Now, it may be useful to provide a management interface for defining the
 schema mapping.  I haven't approached that yet; AFAICT this is where the
 work done on SmartObjects and DBObjects would be very useful.  Initially
 I was planning for people to code the mapping purely in Python so we
 could gain experience and find common patterns before inventing a UI.

 Shane

 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )

-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] External transaction integration bug?

2001-04-19 Thread John D. Heintz

I can't directly address the concerns you've raised, but for my project 
I have rewritten TM.py to work better within the begin/vote/finish/abort 
protocol framework.  I've also added more documentation.

John

Randall F. Kern wrote:

 I may just be missing something obvious here, but it seems like there is
 a hole in ZODB.Transaction.Transaction.commit and Shared.DC.ZRDB.TM.TM,
 that can cause external transactions (those that use the TM mixin class,
 like psycopg) to be abandoned (never get committed or rolled back).
 
 Let's say somewhere around line 300 in Transaction.py (the call to
 j.commit(o, self)) we get an exception.  Furthermore, let's say the TM
 derived database object has already been committed (the only effect of
 which is to move the DB into the jars mapping, since TM.tpc_begin() and
 TM.commit() both do nothing).
 
 The exception dumps us down to about line 353, where we call
 _p_jar.abort() on all the uncommitted objects (note: it's important that
 the database connection isn't in this list, because TM.abort() will
 rollback the transaction.  the way we keep the db out of this list is by
 having it appear in objects _before_ the object that failed the commit).
 
 Next we reach line ~366, where we should "unwind TPC for the jars that
 began it".  What this means is calling tpc_abort() on each jar from the
 objects that were already committed (which includes the database).
 However, TM.tpc_abort() does nothing, leaving the external database
 transaction open.
 
 Does this make sense?
 
 If this makes sense (i.e. seems bad :), does catching tpc_abort() in TM
 and calling TM.abort() seem like a valid fix?
 
 Thanks,
 -Randy
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 
 
 




##
# 
# Zope Public License (ZPL) Version 1.0
# -
# 
# Copyright (c) Digital Creations.  All rights reserved.
# 
# This license has been certified as Open Source(tm).
# 
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
# 
# 1. Redistributions in source code must retain the above copyright
#notice, this list of conditions, and the following disclaimer.
# 
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions, and the following disclaimer in
#the documentation and/or other materials provided with the
#distribution.
# 
# 3. Digital Creations requests that attribution be given to Zope
#in any manner possible. Zope includes a "Powered by Zope"
#button that is installed by default. While it is not a license
#violation to remove this button, it is requested that the
#attribution remain. A significant investment has been put
#into Zope, and this effort will continue if the Zope community
#continues to grow. This is one way to assure that growth.
# 
# 4. All advertising materials and documentation mentioning
#features derived from or use of this software must display
#the following acknowledgement:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#In the event that the product being advertised includes an
#intact Zope distribution (with copyright and license included)
#then this clause is waived.
# 
# 5. Names associated with Zope or Digital Creations must not be used to
#endorse or promote products derived from this software without
#prior written permission from Digital Creations.
# 
# 6. Modified redistributions of any form whatsoever must retain
#the following acknowledgment:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#Intact (re-)distributions of any official Zope release do not
#require an external acknowledgement.
# 
# 7. Modifications are encouraged but must be packaged separately as
#patches to official Zope releases.  Distributions that do not
#clearly separate the patches from the original work must be clearly
#labeled as unofficial distributions.  Modifications which do not
#carry the name Zope may be packaged in any form, as long as they
#conform to all of the clauses above.
# 
# 
# Disclaimer
# 
#   THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY
#   EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
#   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
#   PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL DIGITAL CREATIONS OR ITS

Re: [Zope-dev] FTP interface being worked on?

2001-03-19 Thread John D. Heintz
ur immediate need (which is to allow a distributed team
 of developers to share code and track changes via a central CVS
 repository), maybe it makes the most sense just to segment the existing
 XML export into directories and files and enhance the existing import to
 allow overwriting objects.
 
 
 b) A hybrid XML and custom dump solution.  An Image for
 example could dump out as a binary image file with meta-data in a
 similiarly name XML file.
 
 Yes, each object should make its own policy regarding its
 body.  Its metadata format should be standardized, however.
 
 
 I like this idea.
 
 After I have the XML export/import working in a way that fits better
 with CVS (even if the sreialized representation is essentially a black
 box), then I can tackle how each object represents its body in a
 "morally plain text" serialized format.

I want to add here that it may be very useful to not specify that any 
object have only one serial format separate from the XML default.

Specifically it might make it an easier problem if the author of the 
export code for a type of object can dump property "x" as 
object-name-x.format and property "y" as object-name-y.format

For example instead of just:
|
-- foo_page.xml
-- foo_page.dtml

it might be useful to have arbitrary other files created when foo_page 
is dumped:
|
-- foo_page.xml
-- foo_page.dtml
-- foo_page-description.txt

This would imply that the description property is not captured in the 
foo_page.xml,but instead the easier to use text file.

I'm worried about the parsing complexity when trying to build a single 
"morally plain text" serialized format, and I think that "morally plain" 
can be applied at a sub-object level to make it easier to work with.

The example that comes to mind it Image:
|
-- icon.xml
-- icon.png
-- icon-description.txt

The "morally plain" output here would be binary, not text.  A single 
output file would be hard pressed to allow binary and text editing in 
the same file.

John



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] FTP interface being worked on?

2001-03-19 Thread John D. Heintz

Chris McDonough wrote:

 I think there is really only one issue nobody has been able to sort out:
 do we want the objects to be actually stored on the filesystem or do we
 want to be able to mirror a ZODB?  Or do we want both?
 
 
 My conception of it is that objects won't be served from the filesystem, but
 just put in a editable serialized format for version control and tool
 purposes.

How useful/difficult would it be to put the SMB protocol on top of a ZEO 
server?  As serialized formats are build, would this be useful to anyone?

Another use for this that I think would be great for is schema 
migration.  Right now with ZODB we can have custom __setstate__() 
methods that do schema migration, but being able to perform text 
processing changes with common tools would be great.

Just thinking out loud...

 
 
 Nobody wants to edit XML, AFAICT.
 
 Careful, that's a religious issue in some circles. :-)  I know of many
 people who prefer that data be stored in XML just because humans can
 read and change it if the need arises.  (This from a guy who has
 actually edited ZODB XML export files. :-) 

 
 
 Eek.  ;-)
 
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] FTP interface being worked on?

2001-03-18 Thread John D. Heintz
mmand
 line).
 
 
 If you want a lossless "morally binary" representation, it's
 probably best to use XML export, which is great for your
 purposes, because it already exists!  ;-)
 
 
 I've heard it said that all progress is due to the unreasonable man.  So
 to do my part for progress, what I want is a lossless "morally plain
 text" representation. ;-)
 
 If the existing XML export really was great for our purposes, I'd be
 done!  The problem is that everything comes out in one big monolithic
 file.  That's not good for project management using CVS.  (At least, as
 far as I can tell.)
 
 I think there is the potential for a really good solution that solves
 our need to manage our project via CVS, and to solve the greater need to
 enhance the Zope management interface to support tools that work with
 filesystem objects.
 
 I am about to jump into this project next week.  I do want to stay in
 touch with anyone who is working on similar projects, so please keep in
 touch!  I will post reports as I make progress in case anyone is
 interested.
 
 Thanks,
 Fred



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] is there a hook for before the transaction is committed

2001-03-05 Thread John D. Heintz

Hi Tim,

I have two suggestions, I hope one of them helps.

1) Attached is a TM.py file that I wrote based on the one you mention 
below.  I've tried to make it more obvious and better documented.

2) Don't use this kind of functionality, but rather use sub-transaction 
commits.

The first suggestion has more overhead than what I assume you would 
need, but the second one won't work for all situations.

A Fishbowl proposal of mine, HashingSupport, was going to use the same 
kind of hook you are asking about.  In this case though, using 
sub-transaction commits made a lot more sense.

In general though, I think that _v_* attributes pose a non-trivial 
problem that probably requires a hook on abort() if not commit() as well.

John

Tim McLaughlin wrote:

 Is there a hook for before the transaction is committed for objects which
 subclass Persistent?  I found __inform_commit__ for a "registered" object,
 but I can't seem to get that to work as I thought it did.  I also tried
 subclassing TM like a DA, but to no avail.
 
 TIA,
 Tim
 
 ___
 Tim McLaughlinBCSwebservices.net
 Director, Technical Group 1950 Old Gallows Road
 tel:  (703) 790.8081 x111 Suite 201
 [EMAIL PROTECTED]Vienna, VA 22182
 www .bcswebservices. net
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


##
# 
# Zope Public License (ZPL) Version 1.0
# -
# 
# Copyright (c) Digital Creations.  All rights reserved.
# 
# This license has been certified as Open Source(tm).
# 
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are
# met:
# 
# 1. Redistributions in source code must retain the above copyright
#notice, this list of conditions, and the following disclaimer.
# 
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions, and the following disclaimer in
#the documentation and/or other materials provided with the
#distribution.
# 
# 3. Digital Creations requests that attribution be given to Zope
#in any manner possible. Zope includes a "Powered by Zope"
#button that is installed by default. While it is not a license
#violation to remove this button, it is requested that the
#attribution remain. A significant investment has been put
#into Zope, and this effort will continue if the Zope community
#continues to grow. This is one way to assure that growth.
# 
# 4. All advertising materials and documentation mentioning
#features derived from or use of this software must display
#the following acknowledgement:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#In the event that the product being advertised includes an
#intact Zope distribution (with copyright and license included)
#then this clause is waived.
# 
# 5. Names associated with Zope or Digital Creations must not be used to
#endorse or promote products derived from this software without
#prior written permission from Digital Creations.
# 
# 6. Modified redistributions of any form whatsoever must retain
#the following acknowledgment:
# 
#  "This product includes software developed by Digital Creations
#  for use in the Z Object Publishing Environment
#  (http://www.zope.org/)."
# 
#Intact (re-)distributions of any official Zope release do not
#require an external acknowledgement.
# 
# 7. Modifications are encouraged but must be packaged separately as
#patches to official Zope releases.  Distributions that do not
#clearly separate the patches from the original work must be clearly
#labeled as unofficial distributions.  Modifications which do not
#carry the name Zope may be packaged in any form, as long as they
#conform to all of the clauses above.
# 
# 
# Disclaimer
# 
#   THIS SOFTWARE IS PROVIDED BY DIGITAL CREATIONS ``AS IS'' AND ANY
#   EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
#   IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
#   PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL DIGITAL CREATIONS OR ITS
#   CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDI

Re: [Zope-dev] is there a hook for before the transaction is comm itted

2001-03-05 Thread John D. Heintz

Hi Tim,

I'm glad that worked for you.  I think _vote() is the right place to do 
what you want.

See my reply to Steve Alexander for my comments on _v_* attributes.

John

Tim McLaughlin wrote:

 In what respect are the _v_* attribs gonna cause problems.  My guestimate
 was that they disappeared upon transaction commit/abort.  I'm also not sure
 as to why I would need subtrans since I'm only messing with properties of
 the object.  To my knowledge, subtrans are only necessary to conserve
 resources.  Anyway, what you gave me works!  Thanks.  It seems I need to
 override the _vote method (since it is only called once and allows
 exceptions).  As to the other stuff, I'm sure you can enlighten me further
 as to why.  I appreciate the help.
 
 Cheers.
 Tim
 
 -Original Message-
 From: John D. Heintz [mailto:[EMAIL PROTECTED]]
 Sent: Monday, March 05, 2001 12:45 PM
 To: Tim McLaughlin
 Cc: '[EMAIL PROTECTED]'
 Subject: Re: [Zope-dev] is there a hook for before the transaction is
 committed
 
 
 Hi Tim,
 
 I have two suggestions, I hope one of them helps.
 
 1) Attached is a TM.py file that I wrote based on the one you mention 
 below.  I've tried to make it more obvious and better documented.
 
 2) Don't use this kind of functionality, but rather use sub-transaction 
 commits.
 
 The first suggestion has more overhead than what I assume you would 
 need, but the second one won't work for all situations.
 
 A Fishbowl proposal of mine, HashingSupport, was going to use the same 
 kind of hook you are asking about.  In this case though, using 
 sub-transaction commits made a lot more sense.
 
 In general though, I think that _v_* attributes pose a non-trivial 
 problem that probably requires a hook on abort() if not commit() as well.
 
 John
 
 Tim McLaughlin wrote:
 
 
 Is there a hook for before the transaction is committed for objects which
 subclass Persistent?  I found __inform_commit__ for a "registered" object,
 but I can't seem to get that to work as I thought it did.  I also tried
 subclassing TM like a DA, but to no avail.
 
 TIA,
 Tim
 
 ___
 Tim McLaughlin   BCSwebservices.net
 Director, Technical Group1950 Old Gallows Road
 tel:  (703) 790.8081 x111Suite 201
 [EMAIL PROTECTED]   Vienna, VA 22182
 www .bcswebservices. net
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] is there a hook for before the transaction is committed

2001-03-05 Thread John D. Heintz

Hi Steve,

ZPatterns is something that is very high on my must investigate list, 
but I am not doing Zope development, but rather ZODB based development.

I'm sure that I can still get lots of good ideas though...

My comment below about _v_* attributes is primarily about not using 
functionality like Keeper or TM, but rather just taking advantage of 
_v_* attributes for caching purposes.

What I would want from caching, volatile variables is to reset only when 
the object, or more safely the session, has conflicted and needs to be 
reset.

I wouldn't want to take the performance hit for the cases where I have 
only successful commits on the same Connection cache of objects.  In 
that case I would needlessly be reseting my volatile cache.

In our code we are overriding _p_deactivate() like this:
def __p_deactivate__(self):
temp = _v_something
Persistent.__p_deactive__(self)
_v_something

We are only doing this for instance vars that are not sensitive to 
commit/abort cycles.

I think that the ideal situation would allow the volative cache to be 
reset only in the case of a Conflict, i.e. abort()

There are two scopes that this can happen at:
1) The _v_* vars that are only local to the Persistent object that they 
are defined within.

This would be a __p_reset__() method or something that is called by the 
ZODB Connection mechanism.

2) Session wide, i.e. _v_* vars that are dependent on multi-object state 
but happen to be stored on one of the Persistent objects.

This would be handled by Keeper or TM like solutions.

Anyway, this is just my current mental state dump.  ;-)

Thanks,
John

Steve Alexander wrote:

 John D. Heintz wrote:
 
 Hi Tim,
 
 I have two suggestions, I hope one of them helps.
 
 1) Attached is a TM.py file that I wrote based on the one you mention 
 below.  I've tried to make it more obvious and better documented.
 
 2) Don't use this kind of functionality, but rather use 
 sub-transaction commits.
 
 The first suggestion has more overhead than what I assume you would 
 need, but the second one won't work for all situations.
 
 A Fishbowl proposal of mine, HashingSupport, was going to use the same 
 kind of hook you are asking about.  In this case though, using 
 sub-transaction commits made a lot more sense.
 
 In general though, I think that _v_* attributes pose a non-trivial 
 problem that probably requires a hook on abort() if not commit() as well.
 
 
 
 Take a look at ZPatterns; specifically, the classes Keeper and Kept from 
 ZPatterns/Transactions.py
 
 You can see examples of how they are used in DataSkins.py and Rack.py, 
 although there really isn't much to it.
 
 I've included the docstrings below.
 
 class Keeper:
 """Resets an object's per-transaction cache attributes at txn boundaries
Note that Keepers are created by Kept objects semi-automatically, 
 and   there is usually no need to create one manually.  A Keeper
automatically registers itself with the Zope transaction upon
creation, and instructs its Kept client to clear its per-transaction
cache at all transaction boundaries.  Keeper methods are called only
by the Zope transaction, so don't mess with them."""
 
 
 class Kept(Base):
 """Thing which has a Keeper to clear its per-transaction cache.
 
 Objects derived from Kept should reference the 'self._v_Keeper'
 attribute whenever they need to flag that they have made changes to
 their cache that would require it to be cleared.  (Note that
 '_v_Keeper' is an *attribute*, not a method, and so should not be
 called, just referenced.)
 
 Once this has been done, the next transaction state transition
 that occurs (sub/main transaction commit or abort) will cause
 the object's Keeper to call for a cache reset.
 
 Subclasses of Kept should define a '__per_transaction_cache_attrs__'
 attribute as a sequence of attributes which they would like to have
 deleted from their '__dict__' at reset time.
 """



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Storing part of an object on the file system

2001-02-22 Thread John D. Heintz

Andy,

I'm just checking an assumption that I'm making about the Ext* Products:
They do no work out of the box with ZEO, right?

That is, they would require some sort of shared network drive for all 
ZEO clients to functions correctly.

Thanks,
John

Andy McKay wrote:

 Actually just follow up I realised I never told you how I solved this
 problem. I compacted all data types into File, Image or DTML Document. Since
 I had ExtFile and ExtImage I chopped those into one class called it
 ExtThing, and the wrote classes off it. ExtFile and ExtImage I cut and
 pasted (not complete) for the most part.
 
 Then I wrote a class that called ExtHTML that is a DTML Document that
 overrides the munge() and read() read functions. Instead I passed those onto
 ExtThing. And there you go a DTML Document that has the main body stored on
 the local file system.
 
 Thanks McGregor.
 --
   Andy McKay.
 
 
 - Original Message -
 From: "Andy McKay" [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Thursday, February 08, 2001 4:15 PM
 Subject: [Zope-dev] Storing part of an object on the file system
 
 
 
 Ok whack idea #34... Well sort of, the idea was sparked by ExtFile (yes
 
 its
 
 all his fault honest). We want to have files on the file system for many
 reasons which I won't go into now, just take it for granted. But we also
 want some of the objects information to be in the standard data.fs, so we
 can catalog it use acquisition provide a simple interface to it and so on.
 So far you are saying thats ExtFile and you are right.
 
 But we want to extend it to any object anywhere, instead of storing the
 
 data
 
 attribute in the object and pickling it in the ZODB I want to be able to
 store the data attribute on the file system. This gives us loads of
 advantages we also thought this would be extremely useful to other people.
 We've bounced around ideas on how to do this and here the only two so far:
 
 -we could overload the data attribute with a class that on Pickling
 
 into
 
 the ZODB instead writes it on to the filesystem...
 -we could in the ZODB put a hack to say if pickling something with so
 and so attribute do this instead...
 
 I feel like this something I should just not be doing, but it would be
 
 great
 
 if I could get it work...
 
 --
   Andy McKay.
 
 
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )
 
 
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Q: Specialists, Racks, and ZCatalogs?

2001-02-05 Thread John D. Heintz

Wow, it's fun to hear people talking about Catalysis!

Catalysis is an analysis and design methodology that focuses on 
components and frameworks.  It stresses being able to specify component 
interactions with invariants, pre/post conditions, and supporting graphics.

The book, "Objects, Components, and Frameworks with UML" by Desmond 
D'Souza and Alan Wills is no light read, but well worth it.  Composing 
multiple frameworks together with package substitutions is really cool. ;-)

We are actually combining the analysis precision from Catalysis with the 
code focus from XP and having really good success.

John "who worked for Desmond in past life" Heintz



Johan Carlsson wrote:

 ...
 When you're thinking about a system, it is often helpful to think about
 just a part of the system rather than the system as a whole. To do this, 
 you define a limited "scope" around a particular subsystem.
 In this case, an Actor represents the role something from outside your
 subsystem plays when interacting with something inside your subsystem.
 
 The "something" can be an object, a person, a separate computer system,
 a corporation...
 
 
 
 Thanks Steve,
 You cleared up my confusion.
  
 
 How should I look at roles in ZPatterns?
 
 This is all standard object-oriented stuff, and is not specific to ZPatterns.
 Get the Coad book, read it, and things should get clearer :-)
 
 
 It's on my ToReadList :-)
  
 
 
 Also, the Catalysis method puts an emphasis on defining interactions and 
 collaborations between objects in terms of roles. You might want to take
 a look at that.
 
 
 Is Catalysis method a pattern in Coads book?
 
 Regards,
 Johan Carlsson
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] How would I keep _v_* attributes from getting thrown away?

2001-01-22 Thread John D. Heintz

Thanks for the warning Dieter,

but I'm managing threads/connections/sessions/POAs and a few other 
things already to expose ZODB objects through CORBA sessions.

I wanted the _v_* attributes to live for the life of the DB Connections.

Last night I found a fix for the bug that prevented me from overriding 
the _p_deactivate() method on Persistent objects, so I think that I will 
just do this:

class ...
def _p_deactivate(self):
temp_position = self._v_position
Persistent._p_deactivate(self)
self._v_position = temp_position


Thanks for the help though.

John

Dieter Maurer wrote:

 John D. Heintz writes:
   I am using ZODB along with CORBA to expose peristent objects.  Some of 
   my objects have per-connection/session state.
   ...
   My initial idea is to have a _v_position attribute ...
 Using "_v_" attributes for session state is a very bad idea.
 They are thread(!) local and not session local.
 This means, if a following request of your user (in the same session)
 happens to get assigned a different thread, it will read
 and update a different position. Chaos is garanteed (though you
 will see it only, if your site is loaded).
 
 Use a session product (- zope.org) for session data.
 
 
 Dieter
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Better test case for Bug 1783: Persistent __call_method__() interferes with __getstate__

2001-01-20 Thread John D. Heintz

Hello all,

The following is the best test case I have so far for bug 1783.

The behavior of the bug is that no CMethods from Persistent can be 
called indirectly when the __call_method__ hook is present.  This means 
that I can't override any of __getstate__, __setstate__, _p_deactivate.

#!/usr/bin/python
import ZODB
from Persistence import Persistent

class P(Persistent):
def __call_method__(self, meth, methArgs, methKW={}):
return apply(meth, methArgs, methKW)

p = P()

p.__getstate__()

#This throws exception!
Persistent.__getstate__(p)


TypeError: function requires exactly 0 arguments; 1 given


-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] How would I keep _v_* attributes from getting thrown away?

2001-01-19 Thread John D. Heintz

Hello all,

I am using ZODB along with CORBA to expose peristent objects.  Some of 
my objects have per-connection/session state.  The clear example is 
file-like objects - effectively exposing persistent StringIO objects 
through CORBA.

The issue is that I want multiple clients to be able to read() iterate 
over the same file-like corba objects.

My initial idea is to have a _v_position attribute that is unique for 
each Connection cache object and maintains the correct position in the 
StringIO for each session.  I obviously wouldn't want this to be a 
persistent attribute because a spurious commit would put it into the db 
and mess up any other users iterating through the same object from a 
different session.

A volatile attribute, _v_position, however can be destroyed at any time 
with a cache cleanup via deactivate() call.

How do I maintain volatile, but per connection stable, attributes on 
persistent objects?

I thought about overriding the _p_deactivate() method, but I am also 
defining the __call_method__() hook and am bound by Bug 1783 that 
prevents this kind of thing.

My thoughts on building this into cPersistent.c after looking through 
the code is to provide special processing to not remove some special 
attributes that also don't get saved into the db.

Two ideas come to mind for this:
1) define _vs_* as volatile stable that is neither persisted nor 
clear()ed.  This would slow down the deactivate() method though.

2) define _v_stable as a special volatile that doesn't go away.  This 
would be quick processing in deactivate() and could be a dictionary to 
account for many stable volatile attributes.

Thanks for any help,
John


-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Announcing ZODB-Corba code release

2000-12-13 Thread John D. Heintz

Here is the first release of code that exposes a ZODB database through
CORBA (omniORB).

The code is functioning, the docs are sparse, and it should work on your
machines.  ;-)

I am only going to be in town for the next two days, then I will be
unavailable until Jan 1.

See http://www.zope.org/Members/jheintz/ZODB_CORBA_Connection to
download the code.

It's not perfect, but it works for me.

Enjoy,
John


-- 
.. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Bug reports, feature requests, etc. go in the ZEO Tracker:
http://www.zope.org/Products/ZEO/Tracker

Conversations etc. can take place in the Wiki:
http://www.zope.org/Products/ZEO/Wiki

Zope-ZEO maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-zeo





___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] Significance of the ZODB split?

2000-12-08 Thread John D. Heintz

The Sourceforge exposure gives people like me with an itch to scratch a 
place to work on a publicly visible branch of ZODB for my two proposals 
without breaking anything or relying on patch files continually.

John Heintz

PS My proposals are ExplicitTransactions and PersistentBlob ;-)

Michel Pelletier wrote:

 On Fri, 8 Dec 2000, Robin Becker wrote:
 
 
 Anyone know why AM Kuchling needs to split off a Sourceforge project
 based on ZODB?
 
 
 I don't think it's a "split", but AMK is using ZODB internally at his
 job, and externally with his own projects, so I can see him wanting to
 have some control over the distribution that he uses.  
 
 Other than that, there could be other reasons, we, for example, do not
 provide a mechanism for community checkin privledges, Sourceforge
 does.  I don't think we have a ZODB specific mailing list, sourceforge
 offers this.
 
 That being said, I'm pretty sure we've allways kept up with Andrew's
 patches and suggestions, and we'd be happy to create a mailing list.
 
 Andrew has also extended any developer at DC checkin privledges at the
 sourceforge project; although I suspect we'll just continue to check
 into our CVS and he'll "sync" with us that which he wants.  I am, in
 particular, barely not lazy enough to check stuff into branches, much
 less whole other repositories. ;)
 
 
 I really liked the ZEO examples, but where's this going?
 
 
 It's just open source.  More power to him in my opinion.  He's
 definatly taking Zope and ZEO to new levels and audiences.
 
 -Michel
 
 
 ___
 Zope-Dev maillist  -  [EMAIL PROTECTED]
 http://lists.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists - 
  http://lists.zope.org/mailman/listinfo/zope-announce
  http://lists.zope.org/mailman/listinfo/zope )



-- 
. . . . . . . . . . . . . . . . . . . . . . . .

John D. Heintz | Senior Engineer

1016 La Posada Dr. | Suite 240 | Austin TX 78752
T 512.633.1198 | [EMAIL PROTECTED]

w w w . d a t a c h a n n e l . c o m


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




Re: [Zope-dev] CORBA-ZODB: Is replacing global get_transaction() the only way...

2000-10-04 Thread John D. Heintz
Connection is always associated with one Transaction.  If
  this assumption is true, then it should be safe to make the change I'm
  proposing. If not, then I need to understand why so that I can rethink
  how to solve my problem. ;-)
 
  I hope that I've made my problems and ideas for solutions clear, if not
  please let me know.
 
 I dunno. You'll probably be able to tell from my response. :)

Only the difference between thread/Connection/transaction per request
versus exposing the same cached object across multiple CORBA requests.
 
  Also, I think that I should be able to make the
  changes to ZODB myself within the next few week, but only if there is
  the _possibility_ of folding them back into the main Zope codebase.
 
 I sincerely hope that no ZODB changes are necessary.

This is, in Python, the changes to Persistent that I feel would solve my
problem.  I think that in general this code would allow multiple thread
to modify ZODB objects while still keeping the right transaction up to
date.

import ZODB
from Persistence import Persistent
class TestPersistent(Persistent):
  self __changed__(self):
"Completely ignoring self-state from c code..."

if self._p_jar:
  self._p_jar.transaction.register(self)

and then in DB.py the open() method must add a transaction attribute to
the connection before returning.

I've got one more question.  What happens if I:
- make a connection to a database
- navigate to some objects and store references to them
- make some changes to these objects
- call get_transaction().abort()
- make some changes to the same objects (that I have references to)
- call get_transaction().commit()

Will everything do what I expect in this case?

Thanks so much for you time,
John Heintz


 
  Thanks for any help,
  John D. Heintz
 
  CORBA Threading description:
  CORBA defines the POA, which has two standard threading policies:
  ORB Controlled Model
  Single Threaded Model
 
  The POA is basically a controller for requests to one or more
  distributed objects, with thread policy as one of its parameters.
 
  The first threading policy means whatever the ORB gives you - single or
  multi, and you have to deal with all synchronizations.
 
  The second I consider a mis-nomer because there can be many threads, but
  only one at a time will access objects for a given POA.  (This is the
  model that I perceive being used by default for ZODB object from a
  specific Connection.)
 
 No. Multiple threads can be accessing the same logical object.
 Each thread has it's own copy (and DB connection and transaction).
 
 Jim
 
 --
 Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
 Technical Director   (888) 344-4332http://www.python.org
 Digital Creationshttp://www.digicool.com   http://www.zope.org
 
 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
 address may not be added to any commercial mail list with out my
 permission.  Violation of my privacy with advertising or SPAM will
 result in a suit for a MINIMUM of $500 damages/incident, $1500 for
 repeats.

-- 
John D. Heintz
DataChannel, Inc.
Senior Engineer
512-633-1198
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] Only using ZODB, not Zope Re: New Proposal: PersistentBlob

2000-09-29 Thread John D. Heintz

Hi Greg,

Thanks for the pointer.  I briefly looked at this Product and the
CVSMixin Product as well, but have one requirement that unfortunately I
_didn't_ explain clearly in my proposal.

I am not using Zope, only the ZODB so a Zope Product will not help me.

My first goal with the proposal was to get feedback on if my idea is
correct and what implementation problems could occur, i.e. transactions
and file locking.

My second goal is to inspire someone to implement it and merge it into
the official ZODB.  I think that the idea has enough merit and could be
useful for a large number of applications.

We might have the time and need to implement PersistentBlob ourselves,
but I can't say for sure now.

Thanks all,
John

Gregor Heine wrote:
 
  Hi all,
 
  Yesterday I put up a new proposal on the http://dev.zope.org site that
  documents my vision of PersistentBlob.  The main idea is the be able to
  mark blocks of strings (text or binary) content for storage in a file
  system as individual files.  (Or blobs in a relation table.)
 
  The two motivations for this are keeping a ZODB FileStorage small and
  exposing blocks of string content to external processes (i.e. full-text
  indexing).
 
  Thanks for taking a look.
  John
 
 Hi John!
 
 Have you had a look at the ExtFile Product
 (http://www.zope.org/Members/MacGregor/ExtFile)?
 It basically does all the things you want to achive with the PersistentBlob
 (i.e. storing files externally and making them accessible for external
 processes), except that it's not that deeply integrated into the Zope
 machinery and stores the files only in the file system and not in an RDBMS
 (which nevertheless could be implemented).
 
 Cheers, Gregor!

-- 
John D. Heintz
DataChannel, Inc.
Senior Engineer
512-633-1198
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )




[Zope-dev] New Proposal: PersistentBlob

2000-09-26 Thread John D. Heintz

Hi all,

Yesterday I put up a new proposal on the http://dev.zope.org site that
documents my vision of PersistentBlob.  The main idea is the be able to
mark blocks of strings (text or binary) content for storage in a file
system as individual files.  (Or blobs in a relation table.)

The two motivations for this are keeping a ZODB FileStorage small and
exposing blocks of string content to external processes (i.e. full-text
indexing).

Thanks for taking a look.
John


-- 
John D. Heintz
DataChannel, Inc.
Senior Engineer
512-633-1198
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )