It's not just the legal aspect.
After seeing how poorly Oracle supported OpenOffice, I would be concerned
about their future support for MySQL as well.
On Friday, March 8, 2013 4:43:06 AM UTC-5, Niphlod wrote:
This is going nuts. He was fine until now with SQLite, either one of mysql
or
@Cliff MariaDB!!
:)
Richard
On Fri, Mar 8, 2013 at 7:36 AM, Cliff Kachinske cjk...@gmail.com wrote:
It's not just the legal aspect.
After seeing how poorly Oracle supported OpenOffice, I would be concerned
about their future support for MySQL as well.
On Friday, March 8, 2013 4:43:06
Sorry I misunderstood your previous statement.
On Friday, 8 March 2013 03:09:31 UTC-6, Vineet wrote:
That's true.
But 'Serial' gives four-byte integer (no other option).
In MySQL's autoincrement, we can define it on any size of variable
(tinyint, mediumint, int, etc.).
IMHO, this
web2py works nicely with Firebird DB. Highly recommended.
On Thursday, March 7, 2013 3:41:18 PM UTC-5, BlueShadow wrote:
Hi guys so I learned that using SQLlite for me wasn't a great
choice(thanks Niphlod). But since I started using databases when I started
to use web2py. I got no clue
@Richard
Yeah, I know. But what about documentation?
The MySQL code itself is free open source, but Oracle owns the copyright on
the MySQL documentation.
So as the MariaDB fork adds features, the MySQL documentation becomes more
and more inaccurate. At some point there will have to be a
Thanks Cliff I wasn't about that issue, it's good to know that.
I would be really curious to know if the MySQL user base had splitted since
the MariaDB fork and what the proportion that stays with MySQL and now with
MariaDB...
Richard
On Fri, Mar 8, 2013 at 3:17 PM, Cliff Kachinske
I don't know in terms of user numbers but mysql is getting replaced with
mariadb in Fedora, which will have some impact.
Current plan for Fedora 19 is this:
- mariadb package will provide mysql
- existing mysql package will be renamed to MySQL
- mariadb and MySQL pacakges conflict, they can't be
The only con with postgres is that it doesn't support autoincrement field
by default.
We need to create a 'sequence' and an 'after insert trigger' for it. :(
MySQL has built-in support for auto-increment field.:)
But otherwise, postgres is totally free for any purpose (they say that no
This is not true. In fact web2py uses the PostgreSQL auto increment feature:
create table something {
id SERIAL PRIMARY KEY
}
This is all you need. This is even simpler the mySQL:
CREATE TABLE something (
id MEDIUMINT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id)
) ENGINE=InnoDB;
This
http://web2py.com/books/default/chapter/29/06
*Notice that requires=... is enforced at the level of forms, required=Trueis
enforced at the level of the DAL (insert), while
notnull, unique and ondelete are enforced at the level of the database.
While they sometimes may seem redundant, it is
a, i understand right now, thanks a lot for your detail explaination
niphlod.
--
---
You received this message because you are subscribed to the Google Groups
web2py-users group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
yep, but you have either to:
1. copy over the databases/ folder (the .table files holds the state of the
tables on the db as far as web2py knows, so the 2nd one if doesn't find the
table files thinks it has to create them)
2. set migrate=False for the tables on the 2nd app (so web2py will trust
Awesome !!! Option 2 worked. Thanks.
On Friday, February 15, 2013 10:00:54 AM UTC-6, Niphlod wrote:
yep, but you have either to:
1. copy over the databases/ folder (the .table files holds the state of
the tables on the db as far as web2py knows, so the 2nd one if doesn't find
the table
Will these options also work for database that is on a linux server ?
On Friday, February 15, 2013 10:44:05 AM UTC-6, Hector Magnanao wrote:
Awesome !!! Option 2 worked. Thanks.
On Friday, February 15, 2013 10:00:54 AM UTC-6, Niphlod wrote:
yep, but you have either to:
1. copy over the
web2py is multiplatform. it behaves in the same exact way in every os it
runs into.
On Friday, February 15, 2013 11:25:10 PM UTC+1, Hector Magnanao wrote:
Will these options also work for database that is on a linux server ?
On Friday, February 15, 2013 10:44:05 AM UTC-6, Hector Magnanao
Yup. See here:
http://stackoverflow.com/questions/14724584/web2py-custom-validators
On Wednesday, February 13, 2013 8:48:25 AM UTC-7, BlueShadow wrote:
Hi,
I got a table for my news articles which are normally linked to a table
which specifies the region/country where my news comes from.
I
Assuming there is a field called SiteNews in the form, you could do
something like:
Field('region', 'reference region', requires=IS_IN_DB(...) if notrequest
.vars.SiteNews else None)
Anthony
On Wednesday, February 13, 2013 10:48:25 AM UTC-5, BlueShadow wrote:
Hi,
I got a table for my
In the a common mistake in migrations or simply moving things around is
moving the database but not the metadata itself.
I am wondering if it is better to keep the metadata (.tables files) IN the
database itself instead of on the filesystem?
On Wednesday, December 12, 2012 9:41:22 PM UTC-6,
It can be done. we do it for GAE-SQL and for heroku but it leads to bigger
problems.
On Friday, 14 December 2012 09:53:25 UTC-6, VP wrote:
In the a common mistake in migrations or simply moving things around is
moving the database but not the metadata itself.
I am wondering if it is better
You can see in gluon/contrib/heroku.py how it is done.
It leads on bigger problems because ONLY postgresql allows you multiple
alter tables within a transaction. Therefore the metadata can still get out
of sync (when not using postgresql) and it would be harder to fix.
On Friday, 14 December
I am having a similar problem. I did an insert using crud.create and it
went through, but now I get the error described above whenever I do
anything related to tht table... I tried this, but my notnull constraint
got in the way so I tried:
Are you using sqlite? This is a strange error and it comes from the
database. Perhaps the file got corrupted?
On Wednesday, 12 December 2012 14:18:58 UTC-6, David Tucker wrote:
I am having a similar problem. I did an insert using crud.create and it
went through, but now I get the error
I've narrowed down the problem. I dropped the table then added it again and
started removing fields and doing the create. My problem is a field called
'expiration' that I want to set automatically for the user. My model
includes 3 tables: tiers, groups, and accounts. Each account references the
Finally, I figured out the issue! In order to store a time() from epoch,
your db type cannot be 'time' but instead must be 'float'
The crud.create form I was generating let the erroneous value thru, and the
db wasn't liking it; however, the form within appadmin caught the issue
saying it needed
I am using sqlite... I agree it is strange. I can still do operations on
other tables just fine, and the creation controller does successfully
create the record, but problems occur when trying to read/view it. If the
file is corrupted, how would I go about repairing/replacing it?
On Wednesday,
Good catch. Yet, default values are not validated (for speed reasons)
unless they go through a form.
On Wednesday, 12 December 2012 21:34:12 UTC-6, David Tucker wrote:
Finally, I figured out the issue! In order to store a time() from epoch,
your db type cannot be 'time' but instead must be
@googlegroups.com] Namens
Niphlod
Verzonden: woensdag 28 november 2012 16:23
Aan: web2py@googlegroups.com
Onderwerp: [web2py] Re: Database deadlocks when using SQL Server
do everything without transaction (with autocommit turned off) and
you'll end up probably with an inconsistent database
Thanks for your response. I wasn’t saying “do everything without
transactions”, because you can explicitly start a transaction if I’m not
mistaken. But for the built in CAS functionality it doesn’t work when using
implicit transactions. If you explicitly use a transaction and therefor
do everything without transaction (with autocommit turned off) and you'll
end up probably with an inconsistent database if there is some business
logic involved. If this is only for raw read speed it may be safer, but I
wouldn't post this as something recommended (i.e. a controller that does +1
This is not supported at this time.
On Thursday, 8 November 2012 09:39:24 UTC-6, Jim S wrote:
Hi - I'm wondering if I can specify a table name in db.define_table that
is different than the name that web2py will then use to refer to it.
Example:
case = db.define_table('case',
Not the reply I wanted, but as always, I appreciate the prompt reply.
Certainly something I can work around.
-Jim
On Thu, Nov 8, 2012 at 9:51 AM, Massimo Di Pierro
massimo.dipie...@gmail.com wrote:
This is not supported at this time.
On Thursday, 8 November 2012 09:39:24 UTC-6, Jim S
Ok this is hackish but...
db.__class__.case = property(lambda self: self['`case`'])
Wouldn't putting this in the model after the table definition work well
enough?
Not sure if you don't need to define a setter too.
--
Why did you get a cycle?
On Monday, 8 October 2012 11:25:53 UTC-5, Jose wrote:
Hi,
I want to make the connection to the database within a try block
try:
db = DAL('sqlite://storage.sqlite')
except:
redirect(URL(c='default', f='maintenance'))
but, obviously, this comes into a
El lunes, 8 de octubre de 2012 14:01:44 UTC-3, Massimo Di Pierro escribió:
Why did you get a cycle?
Because when you redirect to the maintenance, run again the model
(connection to the database)
Jose
--
You have different ways:
if request.function!='maintenance':
try:
db = DAL('sqlite://storage.sqlite')
except:
redirect(URL('default', 'maintenance'))
else: db = None
But then you need to check (if db) every time you use db in models.
You can use conditional models:
-
El lunes, 8 de octubre de 2012 14:32:47 UTC-3, Massimo Di Pierro escribió:
You have different ways:
if request.function!='maintenance':
try:
db = DAL('sqlite://storage.sqlite')
except:
redirect(URL('default', 'maintenance'))
else: db = None
But then you need
request.now works, but the point here is that datetime.now() gets called
the first time only. default can be a callable, so using datetime.now
(without parenthesis) works as expected
On Saturday, October 6, 2012 2:47:25 AM UTC+2, Adi wrote:
would default=request.now work in this case?
On
Okay, thanks :)
On Sat, Oct 6, 2012 at 9:19 AM, Niphlod niph...@gmail.com wrote:
request.now works, but the point here is that datetime.now() gets called
the first time only. default can be a callable, so using datetime.now
(without parenthesis) works as expected
On Saturday, October 6,
would default=request.now work in this case?
On Friday, October 5, 2012 8:27:52 PM UTC-4, Saurabh Kumar wrote:
I have a table with follwing schema:
db.define_table('active_connections',
db.Field('user','string'),
db.Field('last_seen','datetime',default=datetime.now()),
)
I am inserting
I was experiencing the same problem, adding db.commit() after my insert
statements fixed it.
--
Cannot reproduce. Which web2py version?
On Sunday, 19 August 2012 15:04:58 UTC-5, Simon Carr wrote:
I am trying to use a datetime type in my database. I have the following
table definition.
db.define_table(
'post',
Field('author',db.auth_user),
1.99.7 (2012-03-04 22:12:08) stable
On 19 August 2012 21:15, Massimo Di Pierro massimo.dipie...@gmail.comwrote:
Cannot reproduce. Which web2py version?
On Sunday, 19 August 2012 15:04:58 UTC-5, Simon Carr wrote:
I am trying to use a datetime type in my database. I have the following
table
The only other thing that might be relevant is that I started off with a
date format and then changed it to a datetime format.
On 19 August 2012 21:15, Massimo Di Pierro massimo.dipie...@gmail.comwrote:
Cannot reproduce. Which web2py version?
On Sunday, 19 August 2012 15:04:58 UTC-5, Simon
OK, that solved it.
I changed the name of the Field and now everything is OK. I assume SQLite
is ignoring the old field.
Thanks
Simon
On 19 August 2012 21:15, Massimo Di Pierro massimo.dipie...@gmail.comwrote:
Cannot reproduce. Which web2py version?
On Sunday, 19 August 2012 15:04:58
On Thu, Jun 28, 2012 at 8:04 AM, Anthony abasta...@gmail.com wrote:
Anyway, you might be better off looking into using the scheduler, or a
third-party task queue like Celery (a web2py Celery plugin was started
at
some point, though not sure it is complete).
I don't understand, how will
On Thu, Jun 28, 2012 at 1:02 AM, Jonathan Lundell jlund...@pobox.com wrote:
The SQLite adapter simulates select for update by wrapping the select+update
in a transaction. Not too efficient, since it has to lock the entire
database, but it'll do it.
Thanks, I wish it worked in the released
Anyway, you might be better off looking into using the scheduler, or a
third-party task queue like Celery (a web2py Celery plugin was started
at
some point, though not sure it is complete).
I don't understand, how will that let me do a read-modify-update
transaction? It seems as
On Sat, Jun 23, 2012 at 1:54 PM, Anthony abasta...@gmail.com wrote:
You're forgetting another layer. DAL leverages on DBAPI
implementation of sql drivers.
Well, that's not exactly good news for transparency and ease of
documentation.
DB API is just a specification for Python database
On Sat, Jun 23, 2012 at 1:24 PM, Anthony abasta...@gmail.com wrote:
No, when autocommit is disabled, that doesn't immediately result in a shared
lock being acquired and held indefinitely. A shared lock is acquired when a
select is made, but only held as long as it takes to actually do the
Well, earlier it was claimed that the DAL for SQLite left autocommit
on,
A quote from my earlier response:
*web2py is just using the Python standard library sqlite3 module. According
to the
docshttp://docs.python.org/library/sqlite3.html#sqlite3-controlling-transactions,
it looks like
Again, with autocommit off:
The server process does a query/select to see if there is any work to
do. This provokes SQLite to acquire a SHARED lock. Then the server
process decides oops, no work to do, let's go to sleep for a minute.
Notice that it does nothing to release that lock.
Some nice assumptions here... are you actually suggesting that:
- could ever be a stable release of web2py out there that will hold the
lock for any pending select ?
- the book suggesting a good behaviour is absolutely wrong ?
Web2py developers and testers in general would spot that in a breeze
On Wed, Jun 27, 2012 at 10:13 AM, Anthony abasta...@gmail.com wrote:
Again, with autocommit off:
The server process does a query/select to see if there is any work to
do. This provokes SQLite to acquire a SHARED lock. Then the server
process decides oops, no work to do, let's go to sleep for a
Yes, it does release the lock, as soon as the select is complete. You do
not
have to do db.commit() after a select.
Please show me where that is documented.
Section 7 of http://www.sqlite.org/lockingv3.html says that ONLY
happens when autocommit is on, and you have stated that it is
SQLite is a file-based database, so has to have more course locking than a
typical client/server database. Other databases have select for update
functionality, which allows you to select a set of records and lock them.
web2py actually supports this, via .select(..., for_update=True).
Anyway,
On Jun 27, 2012, at 9:08 PM, Anthony wrote:
SQLite is a file-based database, so has to have more course locking than a
typical client/server database. Other databases have select for update
functionality, which allows you to select a set of records and lock them.
web2py actually supports
This is all a great unearthing of the Mystery of Transactions. Thanks for
the investigation, Doug.
This was difficult for me to learn when I got into web2py as well. Perhaps
we could write up all this knowledge somewhere, now that you're figuring it
out?
Can we have a section on Transactions
On Wed, Jun 20, 2012 at 7:04 PM, Niphlod niph...@gmail.com wrote:
You're forgetting another layer. DAL leverages on DBAPI implementation of
sql drivers.
Well, that's not exactly good news for transparency and ease of documentation.
A little more complicated: get on an infinite loop inserting
On Wed, Jun 20, 2012 at 9:06 PM, Anthony abasta...@gmail.com wrote:
Sooo Have I misunderstood the SQLite locking description?
I believe so. The shared lock does not last forever -- only as long as it
takes to execute the select. Once the data have been read, the shared lock
(for that
I believe so. The shared lock does not last forever -- only as long as
it
takes to execute the select. Once the data have been read, the shared
lock
(for that particular select) is released.
Yes, if autocommit is on. The part you didn't quote was that
autocommit can be disabled
You're forgetting another layer. DAL leverages on DBAPI
implementation of
sql drivers.
Well, that's not exactly good news for transparency and ease of
documentation.
DB API is just a specification for Python database drivers to follow to
ensure some degree of similarity and
On Tue, Jun 19, 2012 at 1:33 PM, Anthony abasta...@gmail.com wrote:
I'm not sure it's feasible or desirable for the DAL to try to normalize
every last behavior across all database backends. What exactly would you
have the DAL do differently in this case?
Actually what I'm looking for is in the
I'm looking for The Book to tell me what to expect.
If it doesn't tell me, then I don't know if the current behaviour
(once I discover it) will be carried forward to future versions of
Web2py as part of the backwards compatibility promise, or, if the
current behaviour is just a quirk of
On Tue, Jun 19, 2012 at 3:31 PM, Niphlod niph...@gmail.com wrote:
Yep, I don't know exactly the defaults, but I happen to see some major
differences against various systems with standard python distribution.
Ugh, at least, for the most part, it still all 'just works'. :-/
Moreover, it's just
On Wed, Jun 20, 2012 at 5:53 PM, Anthony abasta...@gmail.com wrote:
Can you explain how whether SQLite autocommits or not matters in this case?
The DAL documentation recommends doing a db.commit() in scripts and
background tasks like this precisely because it doesn't want to assume any
You're forgetting another layer. DAL leverages on DBAPI implementation
of sql drivers.
Actually, there is no begin transaction on python.
Usually you instantiate a cursor, do operations, try to commit, if
exception is raised you rollback.
You can do all kind of tests for your background
Sooo Have I misunderstood the SQLite locking description?
I believe so. The shared lock does not last forever -- only as long as it
takes to execute the select. Once the data have been read, the shared lock
(for that particular select) is released.
Anthony
--
On Mon, Jun 18, 2012 at 2:07 AM, Anthony abasta...@gmail.com wrote:
I don't think web2py is doing any magic -- I think it just relies on the
standard database and database driver behavior.
There in lies the rub - the problem is that The Book isn't really
very easy to use to find out just what
On Mon, Jun 18, 2012 at 4:02 AM, Niphlod niph...@gmail.com wrote:
Ok, just to double check, that is for all DB back-ends or just for SQLite?
This is true for every backend.
Thanks!
Web2py is not blocked, and again, it's only with SQLite that there is the
problem. From the first update on
I don't think web2py is doing any magic -- I think it just relies on the
standard database and database driver behavior.
There in lies the rub - the problem is that The Book isn't really
very easy to use to find out just what the DAL does for each DB and
what shows through as the
I was being half kidding, but only half. :-)
given that that phrase could initiate another round of web2py sucks and
that is actually a simple statement to say that that behaviour occurs only
with standard sqlite, I was not kidding at all :P
Maybe I should make a slice on how to fix
Take it like that. Transactions are a way to provide consistent data to
every reader/writer connected to a database.
Right, I've got that part down, it is the what is the magic that
Web2py is doing behind my back part that I was (and still a little
bit) unclear on.
I don't think
Ok, just to double check, that is for all DB back-ends or just for SQLite?
This is true for every backend.
Ah, OK. So it would be easier to write code that uses any DB except
for SQLite... Hmmm
It's not a question of easier or harder : as always it's just choosing
the right
On Sat, Jun 16, 2012 at 5:56 PM, Niphlod niph...@gmail.com wrote:
The bit of magic that I forgot to tell explicitely is that db.commit()
commits every opened transaction and starts a new one :D
Ok, just to double check, that is for all DB back-ends or just for SQLite?
Note, if your site does
if you're familiar with database transactions, web2py istantiate a new
transaction every request and commit (if no exceptions are thrown
automatically) at the end of the request.
in a module, if you want to roll your own daemon, a transaction is
initiated at the start of the script. You have
On Sat, Jun 16, 2012 at 2:38 PM, Niphlod niph...@gmail.com wrote:
if you're familiar with database transactions, web2py istantiate a new
transaction every request and commit (if no exceptions are thrown
automatically) at the end of the request.
Yup, that part makes sense. And I assume it is
No problem at all.
The bit of magic that I forgot to tell explicitely is that db.commit()
commits every opened transaction and starts a new one :D
just to be precise: locking is true currently only for sqlite engine, and
that's because how sqlite works (it's like that also outside web2py
Of course, silly me. Couldn't see the trees for the forest :-) Thank you
Anthony.
Chris
On Thu, Apr 19, 2012 at 1:20 AM, Anthony abasta...@gmail.com wrote:
db.property.property_type.writable = False
Anthony
On Wednesday, April 18, 2012 4:32:02 PM UTC-4, leftcase wrote:
I've put this
Thanks for confirming this for me, this did seem to be the most sensible
way to approach the problem :-)
Chris
On Wed, Apr 18, 2012 at 1:04 AM, simon simo...@gmail.com wrote:
You can do this with a single form. At the top of the controller set
readable=false, writable=false for the fields
I've put this into the controller to test this out:
def create_newbuild():
#newbuild and resale properties share the same table.
#the extraneous fields are rendered non-writable by the below
db.property.land.writable = False
db.property.reference_number.writable = False
db.property.property_type.writable = False
Anthony
On Wednesday, April 18, 2012 4:32:02 PM UTC-4, leftcase wrote:
I've put this into the controller to test this out:
def create_newbuild():
#newbuild and resale properties share the same table.
#the extraneous fields are rendered
if you need to do common operation with the two sets (old and new),
create a table that maps the larger (as in attributes) set and leave
for the other set the fields not relevant to NULL.
In your case, if old table has more columns, just insert the values from
new leaving all the non relevant
You can do this with a single form. At the top of the controller set
readable=false, writable=false for the fields you do not want on the form.
On Tuesday, 17 April 2012 23:44:54 UTC+1, leftcase wrote:
I'm a new adopter of web2py and I'm trying to learn the framework by
building a simple
For counting SkillLevels that match a Skill with name toto you can use
this:
if db((db.SkillLevel.Skill == db.SkillLevel.id) (db.Skill.Nom ==
toto)).count() == 0:
Select the first item by Nom (for Nome a string):
# you can make .last() or simply .select(), which will return a Rows object
Sorry the first query was wrong:
if db((db.SkillLevel.Skill == db.Skill.id http://db.skilllevel.id/)
(db.Skill.Nom == toto)).count() == 0:
On Thursday, March 29, 2012 11:01:14 AM UTC-3, Alan Etkin wrote:
For counting SkillLevels that match a Skill with name toto you can use
this:
if
In case anyone else is using this, I found that 1.99.7 requires a change at
line 78:
#rows = self.select(query, ['id'], {})
rows = self.select(query, [table['id']], {})
On Monday, July 25, 2011 2:57:05 PM UTC-5, nick name wrote:
Newer version attached, has been tested in one specific
On Tuesday, March 20, 2012 2:30:08 PM UTC-4, Rick Ree wrote:
In case anyone else is using this, I found that 1.99.7 requires a change
at line 78:
#rows = self.select(query, ['id'], {})
rows = self.select(query, [table['id']], {})
Please note that there is a ticket tracking this
I will close that issues because now web2py has _before and _after hooks:
db.table._before_insert.append(lambda fields: None)
db.table._before_update.append(lambda query,fields: None)
db.table._before_delete.append(lambda query: None)
db.table._after_insert.append(lambda fields: None)
Thanks for the advice, Massimo.
Yes, I am calling db.scheduler_task.insert() inside a controller.
On the theory that it could do harm, I put a db.commit() immediately
after the insert and that helped, some.
Now I'm getting the scheduler exception in my worker process about a
third as often, and
Do you do this in a controller?
db.scheduler_task.insert(...)
if not. Make sure you db.commit() immediately after. Would is solve
the problem?
On Feb 27, 9:14 pm, David Phillips david.phillips@gmail.com
wrote:
I am experiencing database deadlocks in a worker processes that is
being
On Wednesday, February 8, 2012 2:16:21 AM UTC-5, Mark Kirkwood wrote:
Sorry, I was not being all that clear. What I meant to say was:
When I try to delete such a record, instead of the form telling me that
the delete was prevented it appears to have succeeded. However a refresh of
the
You are correct, I was clicking the delete button on the grid. Yes, I
think checking the success or otherwise of the Ajax request sounds like
the right thing to do - since calls to the db can fail for all sorts of
reasons, not just constraints.
Regards
Mark
Anthony wrote:
In your case,
+1
but if the Ajax request
fails (which I assume happened in your case), I don't think any feedback is
displayed to the page. Perhaps we should correct that -- first check the
response of the Ajax request, and only remove the row from the grid if it
was successful, otherwise flash an error
Sorry, I was not being all that clear. What I meant to say was:
When I try to delete such a record, instead of the form telling me that
the delete was prevented it appears to have succeeded. However a refresh
of the form shows the record survived (and obviously the database log
tells us why)!
On Tuesday, October 11, 2011 4:04:41 AM UTC-4, spyker wrote:
I have several tables where there should only be one possible combination
of two uuid-fields per table (mostly many to many links).
I have created 'unique' constraints for those fields in Postgresql so the
database would not
Again, if just focused on form validation, I suppose another option would be
to use an onvalidation function (processed after form validation but before
db insert).
Anthony
On Tuesday, October 11, 2011 7:23:33 AM UTC-4, Anthony wrote:
On Tuesday, October 11, 2011 4:04:41 AM UTC-4, spyker
On 11 October 2011 13:25, Anthony abasta...@gmail.com wrote:
Again, if just focused on form validation, I suppose another option would
be to use an onvalidation function (processed after form validation but
before db insert).
Anthony
On Tuesday, October 11, 2011 7:23:33 AM UTC-4, Anthony
On Tue, Oct 11, 2011 at 8:43 AM, Johann Spies johann.sp...@gmail.comwrote:
Thanks Anthony. I will probably make use of what you suggested. I did not
know how to involve the two fields in the form-evaluation. This will not
replace the database constraint: tackling this from both the backend
On 11 October 2011 13:48, Bruno Rocha rochacbr...@gmail.com wrote:
Note that you can use db.table.validate_and_insert and
db.table.validate_and_update to fire validators in pure DAL without forms.
Thanks! I did not know about that.
Regards
Johann
--
May grace and peace be yours in
Good to know.
The difference between
{{rows = dataSet.select()}}
and
{{rows = db.executesql(dataSet._select())}}
is that the former calls the function parse which loops over the
175K rows and converts them into objects.
On Aug 26, 12:08 am, HughBarker hbar...@gmail.com wrote:
Thanks for the
101 - 200 of 282 matches
Mail list logo
