On Tue, May 18, 2010 at 11:31 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 2:57 PM, Nikunj Mehta wrote:
> >
> > On May 18, 2010, at 2:33 PM, Jeremy Orlow wrote:
> >
> > On Tue, May 18, 2010 at 9:36 PM, Shawn Wilsher
> wrote:
> >>
> >> On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
> >>>
> >>>
On Tue, May 18, 2010 at 2:57 PM, Nikunj Mehta wrote:
>
> On May 18, 2010, at 2:33 PM, Jeremy Orlow wrote:
>
> On Tue, May 18, 2010 at 9:36 PM, Shawn Wilsher wrote:
>>
>> On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
>>>
>>> A database connection that locks the entire database cannot be opened if
>>>
On May 18, 2010, at 2:48 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 1:00 PM, Nikunj Mehta wrote:
>>
>> On May 18, 2010, at 12:46 PM, Jonas Sicking wrote:
>>
>>> On Tue, May 18, 2010 at 12:37 PM, Nikunj Mehta wrote:
If the use case here is to avoid tripping up on schema changes, t
On May 18, 2010, at 2:33 PM, Jeremy Orlow wrote:
> On Tue, May 18, 2010 at 9:36 PM, Shawn Wilsher wrote:
> On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
> A database connection that locks the entire database cannot be opened if
> there is another database connection that locks at least one database
On Tue, May 18, 2010 at 1:00 PM, Nikunj Mehta wrote:
>
> On May 18, 2010, at 12:46 PM, Jonas Sicking wrote:
>
>> On Tue, May 18, 2010 at 12:37 PM, Nikunj Mehta wrote:
>>> If the use case here is to avoid tripping up on schema changes, then:
>>>
>>> 1. Lock the database when starting a database co
On Tue, May 18, 2010 at 9:36 PM, Shawn Wilsher wrote:
> On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
>
>> A database connection that locks the entire database cannot be opened if
>> there is another database connection that locks at least one database
>> object, e.g., an index or object store.
>>
>
On May 18, 2010, at 1:36 PM, Shawn Wilsher wrote:
> On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
>> I won't talk about tabs and such. Let's make clarification questions be
>> related to spec text.
> Simply replace any instance of tabs with "database connections".
>
>> A database connection that lo
On 5/18/2010 1:02 PM, Nikunj Mehta wrote:
I won't talk about tabs and such. Let's make clarification questions be related
to spec text.
Simply replace any instance of tabs with "database connections".
A database connection that locks the entire database cannot be opened if there
is another d
I have pointed out three options when dealing with upgrades and concurrency [1]
in a thread started by Pablo and Shawn 6 months ago [2]:
# Allow special DDL like operations at connection time in a special transaction
with spec-based versioning of "schema"
# Combine DDL and DML in ordinary transa
On May 18, 2010, at 12:46 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 12:37 PM, Nikunj Mehta wrote:
>> If the use case here is to avoid tripping up on schema changes, then:
>>
>> 1. Lock the database when starting a database connection. This is the
>> non-sharing access mode defined in
On May 18, 2010, at 12:50 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 12:46 PM, Jonas Sicking wrote:
>> On Tue, May 18, 2010 at 12:37 PM, Nikunj Mehta wrote:
>>> If the use case here is to avoid tripping up on schema changes, then:
>>>
>>> 1. Lock the database when starting a database c
On Tue, May 18, 2010 at 12:46 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 12:37 PM, Nikunj Mehta wrote:
>> If the use case here is to avoid tripping up on schema changes, then:
>>
>> 1. Lock the database when starting a database connection. This is the
>> non-sharing access mode defined i
On Tue, May 18, 2010 at 12:37 PM, Nikunj Mehta wrote:
> If the use case here is to avoid tripping up on schema changes, then:
>
> 1. Lock the database when starting a database connection. This is the
> non-sharing access mode defined in 3.2.9 as the first option under step 2.
Will locking the da
If the use case here is to avoid tripping up on schema changes, then:
1. Lock the database when starting a database connection. This is the
non-sharing access mode defined in 3.2.9 as the first option under step 2.
2. Produce events when an application changes the version so that other tabs of
t
This sounds very similar to the strategy used for WebSQLDatabase.
On Tue, May 18, 2010 at 1:54 AM, Jonas Sicking wrote:
> On Thu, May 13, 2010 at 10:25 AM, Shawn Wilsher
> wrote:
> > On 5/13/2010 7:51 AM, Nikunj Mehta wrote:
> >>
> >> If you search archives you will find a discussion on version
On Tue, May 18, 2010 at 4:09 PM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 3:54 AM, Jeremy Orlow wrote:
> > On Tue, May 18, 2010 at 11:04 AM, Jonas Sicking
> wrote:
> >>
> >> On Tue, May 18, 2010 at 2:42 AM, Jeremy Orlow
> wrote:
> >> > What happens to existing connections that were opene
On Tue, May 18, 2010 at 3:54 AM, Jeremy Orlow wrote:
> On Tue, May 18, 2010 at 11:04 AM, Jonas Sicking wrote:
>>
>> On Tue, May 18, 2010 at 2:42 AM, Jeremy Orlow wrote:
>> > What happens to existing connections that were opened against the
>> > original
>> > database version (once the DB has bee
On Tue, May 18, 2010 at 11:04 AM, Jonas Sicking wrote:
> On Tue, May 18, 2010 at 2:42 AM, Jeremy Orlow wrote:
> > What happens to existing connections that were opened against the
> original
> > database version (once the DB has been updated)?
>
> Once a call to setVersion() has happened, any ex
On Tue, May 18, 2010 at 2:42 AM, Jeremy Orlow wrote:
> What happens to existing connections that were opened against the original
> database version (once the DB has been updated)?
Once a call to setVersion() has happened, any existing connections
will forever fail all requests with a WRONG_VERSI
What happens to existing connections that were opened against the original
database version (once the DB has been updated)?
Are we sure that having versions is really a v1 feature for IndexedDB?
On Tue, May 18, 2010 at 9:54 AM, Jonas Sicking wrote:
> On Thu, May 13, 2010 at 10:25 AM, Shawn Wils
On Thu, May 13, 2010 at 10:25 AM, Shawn Wilsher wrote:
> On 5/13/2010 7:51 AM, Nikunj Mehta wrote:
>>
>> If you search archives you will find a discussion on versioning and that
>> we gave up on doing version management inside the browser and instead leave
>> it to applications to do their own ver
On 5/13/2010 7:51 AM, Nikunj Mehta wrote:
If you search archives you will find a discussion on versioning and that we
gave up on doing version management inside the browser and instead leave it to
applications to do their own versioning and upgrades.
Right, I'm not saying we should manage it, b
If you search archives you will find a discussion on versioning and that we
gave up on doing version management inside the browser and instead leave it to
applications to do their own versioning and upgrades.
Nikunj
On May 12, 2010, at 11:02 AM, Shawn Wilsher wrote:
> Hey all,
>
> A recent con
What does WebSQLDatabase do? I believe the version parameter was based on
that spec.
J
On Wed, May 12, 2010 at 7:02 PM, Shawn Wilsher wrote:
> Hey all,
>
> A recent concern that we have come across at Mozilla is what happens when
> the version changes? Do we silently continue to work and hope
Hey all,
A recent concern that we have come across at Mozilla is what happens
when the version changes? Do we silently continue to work and hope for
the best? Do we throw an error every time saying that the version this
database was opened with is no longer the version of the database? It's
25 matches
Mail list logo
