ZOPE IN WINDOWS, ANY WARNINGS I SHOULD KNOW? .RE: [Zope] crystal reports
thank you Edward, what you say make a lot of sense, although, I will try to do that, I am sure is going to take me some time because I am just starting with zope. I have another question, I have found some people and books who don't advice at all to use Zope on windows system, especially with mysql for windows, is there any problem? I would like to know a real reason for not to (especially if I am going to be using crystal report). Also, I have read in a couple of books that the database that comes with Zope it is not very strong, I want to do a "project" to share pictures with my family (on the other side of the Atlantic), is there any reason for not using the DB that comes with zope. Thank you very much for making this learning experience lot quicker. Rezuma -----Original Message----- From: Edward Muller [mailto:edwardam@interlix.com] Sent: Wednesday, June 25, 2003 12:26 AM To: Ramon Linan Cc: zope@zope.org Subject: Re: [Zope] crystal reports The following is complete conjecture based on working with python/windows/zope... If you were to run the zope server on windows and install the complete python-win32 utilities you could connect python to Crystal Reports via COM/ActiveX and make calls to the Crystal Reports API. If you could then get the Crystal Reports COM/ActiveX control to spit out HTML you could then capture that and use it as you need it. The above would require at least writing some of your own external methods or a product. Plus you would have to understand COM programming under python-win32 (which isn't really that hard). A few years ago I made an Outlook/Exchange <-python -> XMLRPC gateway. It used python-win32's COM support and the DMAPI/MAPI (whatever they are called) APIs of Outlook/Exchange and exposed it via XMLRPC. It was neat. On Tue, 2003-06-24 at 15:26, Ramon Linan wrote:
Hi, anyone knows if there is a product that allow you to use already created crystal reports?
Is also welcome advice about reporting tools to use with ODBC database connection.
Thanks
(very new at this)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev ) -- Edward Muller
Interlix (http://www.interlix.com) Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Web Hosting - PC Service & Support - Custom Programming - Network Service & Support Specializing in Open Source Solutions
On Wed, 2003-06-25 at 08:04, Ramon Linan wrote:
thank you Edward, what you say make a lot of sense, although, I will try to do that, I am sure is going to take me some time because I am just starting with zope.
I have another question, I have found some people and books who don't advice at all to use Zope on windows system, especially with mysql for windows, is there any problem? I would like to know a real reason for not to (especially if I am going to be using crystal report).
wrt to crystal reports and mysql/zope ... I dunno ... Last time I ran zope on windows it was at or near version 2.1 something.... It crashed a lot ... that was all I remember... So I can't speak about how well current versions run.
Also, I have read in a couple of books that the database that comes with Zope it is not very strong, I want to do a "project" to share pictures with my family (on the other side of the Atlantic), is there any reason for not using the DB that comes with zope.
Zope's database is an Object Database ... Not a Relational database ... For something like pictures,where pictures (objects) are organized in logical groups (folders ... another object that can contain other objects) ZODB is fine. Although for ease of use you may want to store the pictures on the local file system.
Thank you very much for making this learning experience lot quicker.
Rezuma
-----Original Message----- From: Edward Muller [mailto:edwardam@interlix.com] Sent: Wednesday, June 25, 2003 12:26 AM To: Ramon Linan Cc: zope@zope.org Subject: Re: [Zope] crystal reports
The following is complete conjecture based on working with python/windows/zope...
If you were to run the zope server on windows and install the complete python-win32 utilities you could connect python to Crystal Reports via COM/ActiveX and make calls to the Crystal Reports API. If you could then get the Crystal Reports COM/ActiveX control to spit out HTML you could then capture that and use it as you need it.
The above would require at least writing some of your own external methods or a product. Plus you would have to understand COM programming under python-win32 (which isn't really that hard).
A few years ago I made an Outlook/Exchange <-python -> XMLRPC gateway. It used python-win32's COM support and the DMAPI/MAPI (whatever they are called) APIs of Outlook/Exchange and exposed it via XMLRPC. It was neat.
On Tue, 2003-06-24 at 15:26, Ramon Linan wrote:
Hi, anyone knows if there is a product that allow you to use already created crystal reports?
Is also welcome advice about reporting tools to use with ODBC database connection.
Thanks
(very new at this)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Edward Muller Interlix (http://www.interlix.com) Phone: 417-862-0573 - Cell: 417-844-2435 - Fax: 417-862-0572 Web Hosting - PC Service & Support - Custom Programming - Network Service & Support Specializing in Open Source Solutions
On Wednesday 25 June 2003 06:04 am, Ramon Linan wrote:
Also, I have read in a couple of books that the database that comes with Zope it is not very strong, I want to do a "project" to share pictures with my family (on the other side of the Atlantic), is there any reason for not using the DB that comes with zope.
It'll be fine for that purpose. The ZODB with "Filestorage" arrangement that Zope comes with out of the box does indeed have a few flaws: 1) Its structure, being object based, is not as straightforward to understand, browse, or search as a relational database (which is virtually synonymous with "SQL database" nowadays). Nor does it lend itself to examination by SQL tools (you can examine it from the Python interpreter, though). 2) It lacks really good diagnostic and repair tools compared with real filesystems (which includes any Linux or DOS filesystem -- against which it compares poorly in this respect). There *are* a couple of tools, but I have to admit I don't really know how to use them. 3) On some systems (I don't think all, but I could be wrong) it will have a 2-gigabyte limit. Of course, for you to hit this limit, you would have to be a very prolific photographer! 4) Because there are fewer users and it is intrinsically more complex and it is newer, ZODB is not be as well tested as run-of-the-mill SQL databases. So there may be bugs (indeed, I'm pretty sure there are a few, even though it's been stable enough for me). However, I don't think any of these will be a problem for you. I am successfully using a ZODB/Filestorage system for content management on our company's site (it's a small site), and I don't see any reason to avoid it. These problems will occur for much *larger*, *higher-use*, and *longer-term* use than you appear to need. larger -- because of the 2GB limit and the general impracticality of dealing with really large container files. larger/higher-use -- because of the increased probability of database corruption due to program errors, system crashes, etc. No system is perfect, and the ZODB system does not (yet) provide enough repairability to deal with this reality. longer-term -- because the relatively narrow range of tools than can work with ZODB databases means more "lock-in" to the Zope system. Over time, something else may become your preferred system, and you may have more difficulty importing compared to SQL databases which are widespread (even if SQL effectively dies, there will be sufficient demand for coping with legacy databases that import should remain easy). Of course, it's not impossible that there will be an explosion of ZODB tools in the future. Can't address running it on Windows, and you don't want my Linux Zealot opinion, anyway (I advise against running *Tetris* and *Solitaire* on a Windows machine, to be perfectly honest ;-D ). Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Terry Hancock wrote at 2003-6-25 10:34 -0700:
... ZODB/FileStorags flaw ... 1) Its structure, being object based, is not as straightforward to understand ... as a relational database
It can't hardly be more complicated than "outer joins", for example ;-) A relational database essentially supports a single data type: a two dimensional table. The ZODB supports an openly extensible set of data types. This might be considered "less straightforward to understand". It definitely is not a flaw.
... 2) It lacks really good diagnostic and repair tools compared with real filesystems (which includes any Linux or DOS filesystem -- against which it compares poorly in this respect).
They are almost unneeded because the FileStorage structure is so trivial that almost nothing can go wrong (software errors apart). Even a complete crash usually does not destroy it (unlike older Unix or even the DOS file system).
There *are* a couple of tools, but I have to admit I don't really know how to use them.
Can I interprete this as you did not yet felt the need to really look into them, because your FileStorage was not yet corrupted?
3) On some systems (I don't think all, but I could be wrong) it will have a 2-gigabyte limit.
FileStorage does not have this limit. Your Python interpreter might be compiled without large file system support. Use one that is not.
... 4) Because there are fewer users and it is intrinsically more complex and it is newer, ZODB is not be as well tested as run-of-the-mill SQL databases.
I met more severe bugs in Oracle (8i) than in ZODB.
...
Dieter
On Thursday 26 June 2003 22:43, Dieter Maurer wrote:
3) On some systems (I don't think all, but I could be wrong) it will have a 2-gigabyte limit.
FileStorage does not have this limit.
Your Python interpreter might be compiled without large file system support. Use one that is not.
I think its fair to say that the 2G limit is a danger zone, even if not a point of certain failure. PartitionedFileStorage can be used to avoid that danger zone if you prefer. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
On a similar vein, I have a version of Python 2.1.3 for Windows that is compiled with Large file support, if anyone needs this, let me know. On Fri, 27 Jun 2003 10:28:38 +0100, Toby Dickenson <tdickenson@geminidataloggers.com> wrote:
On Thursday 26 June 2003 22:43, Dieter Maurer wrote:
3) On some systems (I don't think all, but I could be wrong) it will have a 2-gigabyte limit.
FileStorage does not have this limit.
Your Python interpreter might be compiled without large file system support. Use one that is not.
I think its fair to say that the 2G limit is a danger zone, even if not a point of certain failure. PartitionedFileStorage can be used to avoid that danger zone if you prefer.
-- Phil Harris
Le jeu 26/06/2003 à 23:43, Dieter Maurer a écrit :
A relational database essentially supports a single data type: a two dimensional table.
hmmmmph ! you are not serious, are you ? I don't know of any RDBMS which doesn't support primitive types (int, float, bool, char, string).
The ZODB supports an openly extensible set of data types.
What is more extensible that the combination of primitives types + relations + inclusion constraints ? Lacks encapsulation, inheritance, as in OO ? Hopefully no serious DB backend provides true OO semantics since those don't exist (OO semantics are really defined at the level of the language itself). Relational algebra on the contrary has solid grounds in set and predicate theory. You can map any "OO model" into the relational model. Not the other way around.
This might be considered "less straightforward to understand". It definitely is not a flaw.
The flaw lies in this fact : ODBMS are really hierarchical DBMSes, like the ones of the 60's and 70's that the relational model was supposed to help throw out of the window. That's not to say ZOBD isn't neat and usefull, but please. I just hate when some knowledgeable person spreads FUD on those topics. Aurelien.
On Friday 27 June 2003 09:44 am, Aurélien Campéas wrote:
Le jeu 26/06/2003 à 23:43, Dieter Maurer a écrit :
A relational database essentially supports a single data type: a two dimensional table.
hmmmmph ! you are not serious, are you ?
I don't know of any RDBMS which doesn't support primitive types (int, float, bool, char, string).
What Dieter should have said is "one data structure" -- the components are indeed different types, but the traversability of the structure is limited to the table design. He's right about this, but I assert that that is a *strength* of RDBMs, as much as it is a weakness. It is this simplicity that defends the data from being irrevocably connected with the code that processes it. OOP insists on tightly binding code and data into atomic "objects". That's in fact the whole point of OOP. And it is a really nice idea with loads of useful applications. But it isn't for *everything*. In the long run, programming methods will change and other paradigms will come out, but the basic structure behind, say, a library catalog or a customer database is not going to change! It's like ASCII or the concept of text files themselves -- it's just so dumb simple that it doesn't need re-thinking every few years the way programming techniques do. As for "outer joins" being complicated -- that's a programming problem, not a structural property of the database itself. It is that way precisely because it *isn't* object-oriented.
The ZODB supports an openly extensible set of data types.
What is more extensible that the combination of primitives types + relations + inclusion constraints ?
Well, objects are more flexible -- you can include code unique to the object, mappings (M:M, M:1, 1:M), and all kinds of other structures. Which is terribly useful, but can also be a little too much rope.
Lacks encapsulation, inheritance, as in OO ? Hopefully no serious DB backend provides true OO semantics since those don't exist (OO semantics are really defined at the level of the language itself). Relational algebra on the contrary has solid grounds in set and predicate theory.
You can map any "OO model" into the relational model. Not the other way around.
And that's why people like the OO method -- they don't have to go through the hoops involved in representing the OO model in relational terms. Which does indeed make the front end code more complicated.
This might be considered "less straightforward to understand". It definitely is not a flaw.
The flaw lies in this fact : ODBMS are really hierarchical DBMSes, like the ones of the 60's and 70's that the relational model was supposed to help throw out of the window.
That's not to say ZOBD isn't neat and usefull, but please. I just hate when some knowledgeable person spreads FUD on those topics.
Yeah, that was pretty much my reaction. ZODB is actually great, and the point of my original post was that it was very appropriate for the needs of the original poster. But it is *not* a panacea -- there are still plenty of problem domains for which RDBMs remain superior, and I was outlining where I personally felt the boundaries lay. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
Aurélien Campéas wrote at 2003-6-27 18:44 +0200:
Le jeu 26/06/2003 à 23:43, Dieter Maurer a écrit :
A relational database essentially supports a single data type: a two dimensional table.
hmmmmph ! you are not serious, are you ?
I am...
I don't know of any RDBMS which doesn't support primitive types (int, float, bool, char, string).
That's what the "essentially" was for. But you are right. I should have said: a single data type (relation) beside primitive types.
The ZODB supports an openly extensible set of data types.
What is more extensible that the combination of primitives types + relations + inclusion constraints ?
A data type is data together with operations on this data. A RDB lets you define arbitrary complex relations on primitive types but only very restricted application specific operations.
Lacks encapsulation, inheritance, as in OO ? Hopefully no serious DB backend provides true OO semantics since those don't exist (OO semantics are really defined at the level of the language itself). Relational algebra on the contrary has solid grounds in set and predicate theory.
Set and predicate theory does not restrict relations to be over primitive types only... Whenever you need relations over complex objects you are forced into unnatural auxiliary tables.
You can map any "OO model" into the relational model. Not the other way around.
The relational model *IS* an OO model with a very restricted set of (specialized) object types.
This might be considered "less straightforward to understand". It definitely is not a flaw.
The flaw lies in this fact : ODBMS are really hierarchical DBMSes, like the ones of the 60's and 70's that the relational model was supposed to help throw out of the window.
The ZODB is not hierarchically (although what you see on the surface might look this way). Especially the object types used to build efficient indexes (BTrees) are not hierarchical at all (despite their name).
That's not to say ZOBD isn't neat and usefull, but please. I just hate when some knowledgeable person spreads FUD on those topics.
They see the world differently from you... Dieter
First, thanks to both of you for your answers. Le sam 28/06/2003 à 19:19, Dieter Maurer a écrit :
The ZODB supports an openly extensible set of data types.
What is more extensible that the combination of primitives types + relations + inclusion constraints ?
A data type is data together with operations on this data. A RDB lets you define arbitrary complex relations on primitive types but only very restricted application specific operations.
But this restriction is because of the way most RDBMS are implemented, isnt it ? There's nothing in the relational model that prevent you to bundle specific complex operations with a complex set of relations (I believe : as in "in C, you can do OO-like disciplined programming, like in the Glib or the Linux kernel").
Set and predicate theory does not restrict relations to be over primitive types only...
That's it !
Whenever you need relations over complex objects you are forced into unnatural auxiliary tables.
Unnatural ??? hmm, using something braindead like SQL and pl/sql to programm an RDBMS is off course not only unnatural but totally perverse, yes. Implementations sucks. But I've seen other things, like Datalog, that help me think RDBMS are so bad only because so badly done.
You can map any "OO model" into the relational model. Not the other way around.
The relational model *IS* an OO model with a very restricted set of (specialized) object types.
That's kind of strange. I thought about the OO model in terms of a specific (sub)set of relations types (like inheritance, composition, ownership, etc.)...
This might be considered "less straightforward to understand". It definitely is not a flaw.
The flaw lies in this fact : ODBMS are really hierarchical DBMSes, like the ones of the 60's and 70's that the relational model was supposed to help throw out of the window.
The ZODB is not hierarchically (although what you see on the surface might look this way). Especially the object types used to build efficient indexes (BTrees) are not hierarchical at all (despite their name).
Ok, I know peanuts about the ZOBD - but the fact that it relies on the python pickler to stream in/out objects. The only problem I am aware of with python objects is when you build circular/cyclic structure with them : they won't be reclaimed by the GC whenever a cycle ceases to be referenced by some outer/parent object. So you have to implement explicit destruction (inner dereferencing) of such a structure. Thus the need for a rooted tree, at least an acyclic structure for what lies in the ZOBD (as I understood it). hmmm, I'll dig into this soon. BTW, what do you mean when you say "BTrees are not hierarchical at all" ? The fact that they're seen as a flat ordered collection at the user level ? Or something else ?
That's not to say ZOBD isn't neat and usefull, but please. I just hate when some knowledgeable person spreads FUD on those topics.
They see the world differently from you...
I've been a bit crude, sorry. Thanks for your input. Aurélien.
Aurélien Campéas wrote at 2003-6-29 19:33 +0200:
... Ok, I know peanuts about the ZOBD - but the fact that it relies on the python pickler to stream in/out objects. The only problem I am aware of with python objects is when you build circular/cyclic structure with them : they won't be reclaimed by the GC whenever a cycle ceases to be referenced by some outer/parent object. So you have to implement explicit destruction (inner dereferencing) of such a structure.
Python now has a garbage collector which supplements reference counting (and is able to release most cycles).
Thus the need for a rooted tree, at least an acyclic structure for what lies in the ZOBD (as I understood it).
The ZODB has not problems with circular references. Circular references (in memory) are broken when an object is deactivated (which is controlled by an incremental garbage collector independent of Python's reference counting).
BTW, what do you mean when you say "BTrees are not hierarchical at all" ? The fact that they're seen as a flat ordered collection at the user level ? Or something else ?
To make the typical BTree operations more efficient, there are additional non-hierarchical links in the BTree structure (you can immediately go from a subtree to the left-most leaf and all leaf buckets are linked together).
That's not to say ZOBD isn't neat and usefull, but please. I just hate when some knowledgeable person spreads FUD on those topics.
They see the world differently from you...
I've been a bit crude, sorry.
No problem. Dieter
participants (7)
-
Aurélien Campéas -
Dieter Maurer -
Edward Muller -
Phil Harris -
Ramon Linan -
Terry Hancock -
Toby Dickenson