Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #56213 > unrolled thread

Database statements via python but database left intact

Back to article view | Back to comp.lang.python

Contents

  Database statements via python but database left intact Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> - 2013-10-05 22:16 +0300
    Re: Database statements via python but database left intact Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> - 2013-10-05 22:27 +0300
    Re: Database statements via python but database left intact Zero Piraeus <z@etiol.net> - 2013-10-05 16:29 -0300
      Re: Database statements via python but database left intact Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> - 2013-10-05 22:36 +0300
        Re: Database statements via python but database left intact Ian Kelly <ian.g.kelly@gmail.com> - 2013-10-05 14:31 -0600
          Re: Database statements via python but database left intact Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> - 2013-10-06 00:02 +0300
            Re: Database statements via python but database left intact Ned Batchelder <ned@nedbatchelder.com> - 2013-10-05 17:39 -0400
            Re: Database statements via python but database left intact Chris Angelico <rosuav@gmail.com> - 2013-10-06 09:51 +1100
            Database engine bindings for Python (was: Database statements via python but database left intact) Ben Finney <ben+python@benfinney.id.au> - 2013-10-06 12:05 +1100
            Re: Database engine bindings for Python (was: Database statements via python but database left intact) Chris Angelico <rosuav@gmail.com> - 2013-10-06 12:19 +1100
            Re: Database engine bindings for Python (was: Database statements via python but database left intact) Dan Sommers <dan@tombstonezero.net> - 2013-10-06 06:22 +0000
              Re: Database engine bindings for Python (was: Database statements via python but database left intact) Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-10-06 11:10 +0200
              Re: Database engine bindings for Python (was: Database statements via python but database left intact) Chris Angelico <rosuav@gmail.com> - 2013-10-07 00:37 +1100
                Re: Database engine bindings for Python (was: Database statements via python but database left intact) Roy Smith <roy@panix.com> - 2013-10-06 10:05 -0400
            Re: Database statements via python but database left intact Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-10-06 11:05 +0200
              Re: Database statements via python but database left intact rusi <rustompmody@gmail.com> - 2013-10-06 04:36 -0700
                Re: Database statements via python but database left intact Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-10-06 14:01 +0200
            Re: Database statements via python but database left intact Zero Piraeus <z@etiol.net> - 2013-10-05 18:45 -0300
              Re: Database statements via python but database left intact Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> - 2013-10-06 18:57 +0300
                Re: Database statements via python but database left intact Piet van Oostrum <piet@vanoostrum.org> - 2013-10-06 17:40 -0400
            Re: Database statements via python but database left intact Adam Tauno Williams <awilliam@whitemice.org> - 2013-10-06 11:55 -0400
        Re: Database statements via python but database left intact Adam Tauno Williams <awilliam@whitemice.org> - 2013-10-06 11:52 -0400
          Re: Database statements via python but database left intact Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> - 2013-10-06 19:49 +0300

Page 1 of 2  [1] 2  Next page →

#56213 — Database statements via python but database left intact

Excuse me for asking again today, but i see no error in the following 
code, yes no isertion or update happens into the database:


try:
# locate the ID of the page's URL
cur.execute('''SELECT ID FROM counters WHERE url = %s''', page )
data = cur.fetchone()		#URL is unique, so should only be one
		
if not data:
	#first time for page; primary key is automatic, hit is defaulted
	cur.execute('''INSERT INTO counters (url) VALUES (%s)''', page )
			cID = cur.lastrowid		#get the primary key value of the new added record
else:
	#found the page, save primary key and use it to issue hit UPDATE
	cID = data[0]
	cur.execute('''UPDATE counters SET hits = hits + 1 WHERE ID = %s''', cID )


When this code runs i check instantly my database via PHPMyAdmin and i 
see that it was left intact.

[toc] | [next] | [standalone]

#56215

Actually the whole code is this:

# 
=================================================================================================================
# DATABASE INSERTS -
# 
=================================================================================================================
if cookieID != 1977 and re.search( 
r'(msn|gator|amazon|yandex|reverse|who|cloudflare|fetch|barracuda|spider|google|crawl|pingdom)', 
host ) is None:

	try:
		# locate the ID of the page's URL
		cur.execute('''SELECT ID FROM counters WHERE url = %s''', page )
		data = cur.fetchone()		#URL is unique, so should only be one
		
		if not data:
			#first time for page; primary key is automatic, hit is defaulted
			cur.execute('''INSERT INTO counters (url) VALUES (%s)''', page )
			cID = cur.lastrowid		#get the primary key value of the new added record
		else:
			#found the page, save primary key and use it to issue hit UPDATE
			cID = data[0]
			cur.execute('''UPDATE counters SET hits = hits + 1 WHERE ID = %s''', 
cID )


		# find the visitor record for the (saved) cID and Cookie
		cur.execute('''SELECT * FROM visitors WHERE counterID = %s and 
cookieID = %s''', (cID, cookieID) )
		data = cur.fetchone()		#cookieID is unique
			
		if not data:
			# first time visitor on this page, create new record
			cur.execute('''INSERT INTO visitors (counterID, cookieID, host, city, 
useros, browser, ref, lastvisit) VALUES (%s, %s, %s, %s, %s, %s, %s, 
%s)''', (cID, cookieID, host, city, useros, browser, ref, lastvisit) )
		else:
			# found the page, save its primary key for later use
			vID = data[0]
			# UPDATE record using retrieved vID
			cur.execute('''UPDATE visitors SET host = %s, city = %s, useros = %s, 
browser = %s, ref= %s, hits = hits + 1, lastvisit = %s
						   WHERE counterID = %s and cookieID = %s''', (host, city, useros, 
browser, ref, lastvisit, vID, cookieID) )
		
	except pymysql.ProgrammingError as e:
		print( repr(e) )
		sys.exit(0)

========================

If at some point an error is made does that mean that no 
update/insertion happens?
PEhats that is why iam seeing no entries at all into my database tables?

[toc] | [prev] | [next] | [standalone]

#56216

:

On Sat, Oct 05, 2013 at 10:16:46PM +0300, Νίκος Αλεξόπουλος wrote:
> Excuse me for asking again today, but i see no error in the
> following code, yes no isertion or update happens into the database:
> 
> [...]
> 
> When this code runs i check instantly my database via PHPMyAdmin and
> i see that it was left intact.

Are you sure that you're committing your changes (either by having
autocommit set or using an explicit con.commit() call)?

http://geert.vanderkelen.org/dont-forget-the-commit-in-mysql/

 -[]z.

-- 
Zero Piraeus: inter caetera
http://etiol.net/pubkey.asc

[toc] | [prev] | [next] | [standalone]

#56217

Στις 5/10/2013 10:29 μμ, ο/η Zero Piraeus έγραψε:
> :
>
> On Sat, Oct 05, 2013 at 10:16:46PM +0300, Νίκος Αλεξόπουλος wrote:
>> Excuse me for asking again today, but i see no error in the
>> following code, yes no isertion or update happens into the database:
>>
>> [...]
>>
>> When this code runs i check instantly my database via PHPMyAdmin and
>> i see that it was left intact.
>
> Are you sure that you're committing your changes (either by having
> autocommit set or using an explicit con.commit() call)?
>
> http://geert.vanderkelen.org/dont-forget-the-commit-in-mysql/


I dont think that is the issue, because up until now i never used commit 
and all transaction were successfully were happening.

-- 
What is now proved was at first only imagined! & WebHost
<http://superhost.gr>

[toc] | [prev] | [next] | [standalone]

#56218

On Sat, Oct 5, 2013 at 1:36 PM, Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> wrote:
> Στις 5/10/2013 10:29 μμ, ο/η Zero Piraeus έγραψε:
>>
>> :
>>
>> On Sat, Oct 05, 2013 at 10:16:46PM +0300, Νίκος Αλεξόπουλος wrote:
>>>
>>> Excuse me for asking again today, but i see no error in the
>>> following code, yes no isertion or update happens into the database:
>>>
>>> [...]
>>>
>>>
>>> When this code runs i check instantly my database via PHPMyAdmin and
>>> i see that it was left intact.
>>
>>
>> Are you sure that you're committing your changes (either by having
>> autocommit set or using an explicit con.commit() call)?
>>
>> http://geert.vanderkelen.org/dont-forget-the-commit-in-mysql/
>
>
>
> I dont think that is the issue, because up until now i never used commit and
> all transaction were successfully were happening.

Well, have you changed anything in your database configuration?
Whether MySQL uses transactions or not depends on which storage engine
is being used.  I suggest running a test insert with and without
commit to check whether you actually need it or not.

Also, are you certain that the code is actually being run?  Perhaps
the if condition is evaluating as false and the whole block is being
skipped, or perhaps the code is silently exiting for some reason
before it ever gets to this point.  Do some debugging to determine
what exactly is being executed.

[toc] | [prev] | [next] | [standalone]

#56220

Στις 5/10/2013 11:31 μμ, ο/η Ian Kelly έγραψε:
> Well, have you changed anything in your database configuration?
> Whether MySQL uses transactions or not depends on which storage engine
> is being used.  I suggest running a test insert with and without
> commit to check whether you actually need it or not.


I cannot beleive it!

I have deleted the database and tables and recreted it.
By default it seems to use the InnoDB Engine which wouldn't let anythign 
get inserted/updated.

I then deleted the database recretaed and used at the end fo my create 
table statements the:

create table counters
(
   ID integer(5) not null auto_increment primary key,
   URL varchar(100) not null,
   hits integer(5) not null default 1,
   unique index (URL)
)ENGINE = MYISAM;

After that all mysql queries executed(inserted/updated) properly!

I neved had though of than an engine type could make so much mess.
MyISAM is the way to go then for my web development?
Why InnoDB failed to execute the queries?

[toc] | [prev] | [next] | [standalone]

#56221

On 10/5/13 5:02 PM, Νίκος Αλεξόπουλος wrote:
> Στις 5/10/2013 11:31 μμ, ο/η Ian Kelly έγραψε:
>> Well, have you changed anything in your database configuration?
>> Whether MySQL uses transactions or not depends on which storage engine
>> is being used.  I suggest running a test insert with and without
>> commit to check whether you actually need it or not.
>
>
> I cannot beleive it!
>
> I have deleted the database and tables and recreted it.
> By default it seems to use the InnoDB Engine which wouldn't let 
> anythign get inserted/updated.
>
> I then deleted the database recretaed and used at the end fo my create 
> table statements the:
>
> create table counters
> (
>   ID integer(5) not null auto_increment primary key,
>   URL varchar(100) not null,
>   hits integer(5) not null default 1,
>   unique index (URL)
> )ENGINE = MYISAM;
>
> After that all mysql queries executed(inserted/updated) properly!
>
> I neved had though of than an engine type could make so much mess.
> MyISAM is the way to go then for my web development?
> Why InnoDB failed to execute the queries?

Now is a good time to go read about transactions, and committing, and 
the difference between MyISAM and InnoDB.  Please don't ask more about 
it here.

--Ned.

[toc] | [prev] | [next] | [standalone]

#56225

On Sun, Oct 6, 2013 at 8:39 AM, Ned Batchelder <ned@nedbatchelder.com> wrote:
> Now is a good time to go read about transactions, and committing, and the
> difference between MyISAM and InnoDB.  Please don't ask more about it here.

It's because of threads like this that I would really like Python to
nudge people towards something stronger than MySQL. Would it kill
Python to incorporate PostgreSQL bindings automatically?

ChrisA

[toc] | [prev] | [next] | [standalone]

#56227 — Database engine bindings for Python (was: Database statements via python but database left intact)

Chris Angelico <rosuav@gmail.com> writes:

> It's because of threads like this that I would really like Python to
> nudge people towards something stronger than MySQL. Would it kill
> Python to incorporate PostgreSQL bindings automatically?

I'm not sure what would count as “kill Python”. It would certainly make
the release management of Python needlessly dependent on the release
cycle of an independent project.

The Python bindings for MySQL or PostgreSQL, or even SQLite, are tied to
extension libraries for the specific database engine.

With SQLite this is not a problem for Python's release management,
because Python's release includes the entire SQLite database engine.
That code is quite small, so this is deemed a good trade.

With a separately-installed, far more complex database engine like MySQL
or PostgreSQL, the Python bindings will only work if they are compiled
against the correct client library. That client library is part of the
database engine code release, not Python. So placing that library in
Python's standard library would tie the release of Python's standard
library to the version of the database engine.

I sympathise with the desire to deprecate MySQL and encourage superior
solutions. But your proposed solution would only make Python release
management far more burdensome for an unclear benefit.

-- 
 \      “I tell you the truth: some standing here will not taste death |
  `\     before they see the Son of Man coming in his kingdom.” —Jesus |
_o__)                     Christ, c. 30 CE, as quoted in Matthew 16:28 |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#56229 — Re: Database engine bindings for Python (was: Database statements via python but database left intact)

On Sun, Oct 6, 2013 at 12:05 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> The Python bindings for MySQL or PostgreSQL, or even SQLite, are tied to
> extension libraries for the specific database engine.
>
> With SQLite this is not a problem for Python's release management,
> because Python's release includes the entire SQLite database engine.
> That code is quite small, so this is deemed a good trade.
>
> With a separately-installed, far more complex database engine like MySQL
> or PostgreSQL, the Python bindings will only work if they are compiled
> against the correct client library.

Hmm. I see what you mean. Of course, that doesn't bind Python to a
specific server version, as one version of the client can talk to any
earlier and many later versions of server, but it is an issue.

It'd probably be unreasonable to package libpq with Windows
installations, but with Linux builds, it should be easy enough to link
against whatever libpq happens to be around. If that's unsuited to
your server version, it's going to be broken for any other libpq-based
apps too. (With package managers like apt, same thing - link against
whatever version can be retrieved easily.)

The alternative is a pure-Python implementation of the PostgreSQL wire
protocol. That would most likely be smaller (if the problem is the
size cost of incorporating all of libpq), but would tie Python's pgsql
module to a specific protocol version (which doesn't change very
often). I don't know if one exists already or not, but it ought to be
possible to port the Pike module [1] to Python, if GPL/LGPL/MPL is
compatible with the Python licensing.

ChrisA

[1] http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/Sql/pgsql.html

[toc] | [prev] | [next] | [standalone]

#56238 — Re: Database engine bindings for Python (was: Database statements via python but database left intact)

On Sun, 06 Oct 2013 12:19:13 +1100, Chris Angelico wrote:

> On Sun, Oct 6, 2013 at 12:05 PM, Ben Finney wrote:

[ ... ]

>> With a separately-installed, far more complex database engine like
>> MySQL or PostgreSQL, the Python bindings will only work if they are
>> compiled against the correct client library.

[ ... ]

> The alternative is a pure-Python implementation of the PostgreSQL wire
> protocol ... I don't know if one exists already or not ...

The PostgreSQL Python wiki [0] says that three such implementations do
exist.  Some time ago, before psycopg worked with Python3, I tried
pg8000, and I could access my local databases, but I never got further
than that.

- Dan

[0] http://wiki.postgresql.org/wiki/Python

[toc] | [prev] | [next] | [standalone]

#56243 — Re: Database engine bindings for Python (was: Database statements via python but database left intact)

Reposting what I said in the other thread:

On Sun, Oct 6, 2013 at 12:51 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sun, Oct 6, 2013 at 8:39 AM, Ned Batchelder <ned@nedbatchelder.com> wrote:
>> Now is a good time to go read about transactions, and committing, and the
>> difference between MyISAM and InnoDB.  Please don't ask more about it here.
>
> It's because of threads like this that I would really like Python to
> nudge people towards something stronger than MySQL. Would it kill
> Python to incorporate PostgreSQL bindings automatically?

It would require Postgres around people’s (or at least packagers’)
systems, and it often gets messy when we have such requirements.
Psycopg2, the most popular binding, is licensed under LGPL3 + Zope (or
such, there is a little mess here) which MAY pose a problem (IANAL
though).  Also, Postgres is much harder to configure than MySQL,
especially if you have no experience or an asshole OS.  Moreover, the
stdlib is where packages come to die.

So, instead of this, maybe we should work on getting psycopg2 to the
top result on Googling “python sql”, or even “python mysql” with an
anti-MySQL ad? (like vim was doing some time ago on Googling “emacs”)

We should also educate people on how PostgreSQL works with a nice,
human-friendly tutorial.  Especially in some non-standard things and
things that differ between PostgreSQL and MySQL — like how to make an
auto-incrementing ID field (use sequences), or how PostgreSQL arrays
work, among others.  The wiki (that nobody reads anyways) could also
use some marketing fixes.

-- 
Chris “Kwpolska” Warrick <http://kwpolska.tk>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense

[toc] | [prev] | [next] | [standalone]

#56256 — Re: Database engine bindings for Python (was: Database statements via python but database left intact)

On Sun, Oct 6, 2013 at 8:10 PM, Chris “Kwpolska” Warrick
<kwpolska@gmail.com> wrote:
> It would require Postgres around people’s (or at least packagers’)
> systems, and it often gets messy when we have such requirements.

I would hope that an absence of libpq could simply result in a
courteous exception when the module's imported, but maybe that'd be
hard to implement.

> Also, Postgres is much harder to configure than MySQL,
> especially if you have no experience or an asshole OS.

You can get a ready-to-go Postgres under Debian by simply apt-getting
it. The default config might not give you optimum performance, but
it'll work just fine. Most people shouldn't need to dig into the
configs of _any_ database before getting the app going -
out-of-the-box settings should be fine for early development, even
deployment if you're not doing a lot of traffic.

> Moreover, the stdlib is where packages come to die.

Fair point. That is an issue.

> We should also educate people on how PostgreSQL works with a nice,
> human-friendly tutorial.  Especially in some non-standard things and
> things that differ between PostgreSQL and MySQL — like how to make an
> auto-incrementing ID field (use sequences), or how PostgreSQL arrays
> work, among others.  The wiki (that nobody reads anyways) could also
> use some marketing fixes.

Maybe! Possibly go a bit further and say "How-to: Python and
Databasing", which could mention SQLite (great for something tiny),
PostgreSQL (great for concurrency / multi-user), and "Other databases
can also be used, with similar or identical APIs - check out PyPI for
a module for your favorite database engine".

I guess the above paragraph is sentencing [1] me to write the article, now...

ChrisA

[1] if you'll pardon a terrible pun

[toc] | [prev] | [next] | [standalone]

#56258 — Re: Database engine bindings for Python (was: Database statements via python but database left intact)

In article <mailman.781.1381066683.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> I would hope that an absence of libpq could simply result in a
> courteous exception when the module's imported, but maybe that'd be
> hard to implement.

It works fine.  I've had this in production for a while:

# Psycopg2 is only needed for a single hacky lookup which only happens
# in the station details admin tool.  Installing it has compicated
# dependencies, so don't worry if it's not there.
try:
    import psycopg2
except ImportError:
    psycopg2 = None

[...]

        if psycopg2 is None:
            logger.warning("psycopg2 not installed")
            return None

That being said, I agree that Postgres support does not belong in the 
core product.  Nor does MySQL, or Oracle, or SqlServer, or MongoDB, or 
CouchDB, or Cassandra, or a zillion other databases.  There's a few 
reasons.

One (as several people have already mentioned), it bulks up, and 
complicates, the release process.

The other is that once something is in the core distribution, it become 
the de-facto "right way" to do something, whether it's the best or not.  
From my own experience, I resisted trying nose for quite a while because 
unittest was baked in and it was "good enough".  Ditto for requests vs. 
urllib.

And finally, with something like a database driver, you really don't 
want your release schedule to be tied to the language.  If the postgres 
folks come out with a new database feature (or bug fix) which requires a 
change to the driver, they should be able to release the new driver on 
their own schedule.

[toc] | [prev] | [next] | [standalone]

#56242

On Sun, Oct 6, 2013 at 12:51 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Sun, Oct 6, 2013 at 8:39 AM, Ned Batchelder <ned@nedbatchelder.com> wrote:
>> Now is a good time to go read about transactions, and committing, and the
>> difference between MyISAM and InnoDB.  Please don't ask more about it here.
>
> It's because of threads like this that I would really like Python to
> nudge people towards something stronger than MySQL. Would it kill
> Python to incorporate PostgreSQL bindings automatically?

It would require Postgres around people’s (or at least packagers’)
systems, and it often gets messy when we have such requirements.
Psycopg2, the most popular binding, is licensed under LGPL3 + Zope (or
such, there is a little mess here) which MAY pose a problem (IANAL
though).  Also, Postgres is much harder to configure than MySQL,
especially if you have no experience or an asshole OS.  Moreover, the
stdlib is where packages come to die.

So, instead of this, maybe we should work on getting psycopg2 to the
top result on Googling “python sql”, or even “python mysql” with an
anti-MySQL ad? (like vim was doing some time ago on Googling “emacs”)

We should also educate people on how PostgreSQL works with a nice,
human-friendly tutorial.  Especially in some non-standard things and
things that differ between PostgreSQL and MySQL — like how to make an
auto-incrementing ID field (use sequences), or how PostgreSQL arrays
work, among others.  The wiki (that nobody reads anyways) could also
use some marketing fixes.

-- 
Chris “Kwpolska” Warrick <http://kwpolska.tk>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense

[toc] | [prev] | [next] | [standalone]

#56249

On Sunday, October 6, 2013 2:35:24 PM UTC+5:30, Chris “Kwpolska” Warrick wrote:
> So, instead of this, maybe we should work on getting psycopg2 to the
> top result on Googling “python sql”, or even “python mysql” with an
> anti-MySQL ad? (like vim was doing some time ago on Googling “emacs”)

Do you have any accessible data about this?
Reasons I ask: 
1. The decreasing popularity of emacs wrt vi seems out of proportion to the actual functionality
2. The downward emacs-curve is all the more striking considering the reverse situation some 15-20 years ago

[toc] | [prev] | [next] | [standalone]

#56251

On Sun, Oct 6, 2013 at 1:36 PM, rusi <rustompmody@gmail.com> wrote:
> On Sunday, October 6, 2013 2:35:24 PM UTC+5:30, Chris “Kwpolska” Warrick wrote:
>> So, instead of this, maybe we should work on getting psycopg2 to the
>> top result on Googling “python sql”, or even “python mysql” with an
>> anti-MySQL ad? (like vim was doing some time ago on Googling “emacs”)
>
> Do you have any accessible data about this?
> Reasons I ask:
> 1. The decreasing popularity of emacs wrt vi seems out of proportion to the actual functionality
> 2. The downward emacs-curve is all the more striking considering the reverse situation some 15-20 years ago

I have a screenshot:
https://dl.dropboxusercontent.com/u/1933476/screenshots/emacs.png —
Dropbox claims it was taken at around 2011-03-19T11:32:24Z.  Earlier
today, the exact same ad appeared while searching for “vim”, but not
“emacs” (why bother when you are the first hit for this query
anyways?).

Now, for statistics, how many hits it got, or whatnot — go ask the Vim
developers.

-- 
Chris “Kwpolska” Warrick <http://kwpolska.tk>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense

[toc] | [prev] | [next] | [standalone]

#56264

:

On Sun, Oct 06, 2013 at 12:02:14AM +0300, Νίκος Αλεξόπουλος wrote:
> I neved had though of than an engine type could make so much mess.
> MyISAM is the way to go then for my web development?
> Why InnoDB failed to execute the queries?

Because you didn't commit. MyISAM doesn't support transactions, so when
you use it as the engine, your mistake happens to go unpunished.

Note that this is a weakness of MyISAM cancelling out a failure in your
code; it does *not* mean that MyISAM is better suited to your task.

By the way, Ned's right. At this point, this is no longer a Python
issue, and is off-topic for discussion here.

 -[]z.

-- 
Zero Piraeus: vive ut vivas
http://etiol.net/pubkey.asc

[toc] | [prev] | [next] | [standalone]

#56266

Στις 6/10/2013 12:45 πμ, ο/η Zero Piraeus έγραψε:
> :
>
> On Sun, Oct 06, 2013 at 12:02:14AM +0300, Νίκος Αλεξόπουλος wrote:
>> I neved had though of than an engine type could make so much mess.
>> MyISAM is the way to go then for my web development?
>> Why InnoDB failed to execute the queries?
>
> Because you didn't commit. MyISAM doesn't support transactions, so when
> you use it as the engine, your mistake happens to go unpunished.
>
> Note that this is a weakness of MyISAM cancelling out a failure in your
> code; it does *not* mean that MyISAM is better suited to your task.
>
> By the way, Ned's right. At this point, this is no longer a Python
> issue, and is off-topic for discussion here.
>
>   -[]z.
>
Thanks Zero,

i will use con.commit() from now and on because yesterdays i lost 3 
hours trying to identify what was wrong with my MySQL statements in 
python and it turned out to be for no good reason.

-- 
What is now proved was at first only imagined! & WebHost
<http://superhost.gr>

[toc] | [prev] | [next] | [standalone]

#56284

Νίκος Αλεξόπουλος <nikos.gr33k@gmail.com> writes:

> i will use con.commit() from now and on because yesterdays i lost 3
> hours trying to identify what was wrong with my MySQL statements in
> python and it turned out to be for no good reason.

That shows how important it is to study the software that you are using, and also to study the underlying computer science concepts.
-- 
Piet van Oostrum <piet@vanoostrum.org>
WWW: http://pietvanoostrum.com/
PGP key: [8DAE142BE17999C4]

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web