Suggested query

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Suggested query

decorior
I wanted to write the following multi-statement SQL query. It needs to do the following.

1. DO a search
2. If no search results then insert (create ID)
3. Redo the search
4. IF ID not found n the search then delete record with the ID

Does anyone have any pseudocode suggestions for mySQL

Deco

#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Brad Lindsay
Is it imperative that you don’t use Lasso? Must it all be in SQL?

Brad

On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email]) wrote:

> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>  
> 1. DO a search
> 2. If no search results then insert (create ID)
> 3. Redo the search
> 4. IF ID not found n the search then delete record with the ID
>  
> Does anyone have any pseudocode suggestions for mySQL
>  
> Deco
>  
> #############################################################
>  
> This message is sent to you because you are subscribed to
> the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to:  
> Send administrative queries to  
>  


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
We are looking at seeing if we can get a speed improvement by essentially doing one SQL. We are using DS


> On Nov 27, 2014, at 8:35 AM, Brad Lindsay <[hidden email]> wrote:
>
> Is it imperative that you don’t use Lasso? Must it all be in SQL?
>
> Brad
>
> On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email]) wrote:
>> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>>
>> 1. DO a search
>> 2. If no search results then insert (create ID)
>> 3. Redo the search
>> 4. IF ID not found n the search then delete record with the ID
>>
>> Does anyone have any pseudocode suggestions for mySQL
>>
>> Deco
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to:  
>> Send administrative queries to  
>>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
In reply to this post by Brad Lindsay
We have to worry about concurrency. That is, an insert occurring between the select.

For example:

1.Select to see if I can insert A.
2.B gets inserted
3. Insert A based on the result of 1.

But B would violate 1.

We have bene looking at last_insert_id() but I am not sure if that really helps us here. A final select does the job

4. Select to see if I inserted A first

So there a minimum of THREE insert statements that are needed. So I want to avoid three RTT and make it one.

Deco






> On Nov 27, 2014, at 8:35 AM, Brad Lindsay <[hidden email]> wrote:
>
> Is it imperative that you don’t use Lasso? Must it all be in SQL?
>
> Brad
>
> On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email] <mailto:[hidden email]>) wrote:
>> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>>
>> 1. DO a search
>> 2. If no search results then insert (create ID)
>> 3. Redo the search
>> 4. IF ID not found n the search then delete record with the ID
>>
>> Does anyone have any pseudocode suggestions for mySQL
>>
>> Deco
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to:  
>> Send administrative queries to  
>>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email] <mailto:[hidden email]>
> Official list archives available at http://www.lassotalk.com <http://www.lassotalk.com/>
> To unsubscribe, E-mail to: <[hidden email] <mailto:[hidden email]>>
> Send administrative queries to  <[hidden email] <mailto:[hidden email]>>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Tim Taplin
there is a feature in sql that allows for an insert to check for duplicate key. on duplicate key update

so, assuming that your search step one is to determine whether the record already exists, make sure there is a unique index available, and then do something like:

Insert creating ID on duplicate key update set any values that need updating (set some column = itself if you dont need to update anything )
get last_insert_id()

not sure when you would need to delete the record with this id since you checked to make sure it wasnt there.
Probably need more info on the structure of the data here.

TIm Taplin
 

> On Nov 27, 2014, at 8:57 AM, deco rior <[hidden email]> wrote:
>
> We have to worry about concurrency. That is, an insert occurring between the select.
>
> For example:
>
> 1.Select to see if I can insert A.
> 2.B gets inserted
> 3. Insert A based on the result of 1.
>
> But B would violate 1.
>
> We have bene looking at last_insert_id() but I am not sure if that really helps us here. A final select does the job
>
> 4. Select to see if I inserted A first
>
> So there a minimum of THREE insert statements that are needed. So I want to avoid three RTT and make it one.
>
> Deco
>
>
>
>
>
>
>> On Nov 27, 2014, at 8:35 AM, Brad Lindsay <[hidden email]> wrote:
>>
>> Is it imperative that you don’t use Lasso? Must it all be in SQL?
>>
>> Brad
>>
>> On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email] <mailto:[hidden email]>) wrote:
>>> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>>>
>>> 1. DO a search
>>> 2. If no search results then insert (create ID)
>>> 3. Redo the search
>>> 4. IF ID not found n the search then delete record with the ID
>>>
>>> Does anyone have any pseudocode suggestions for mySQL
>>>
>>> Deco
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>> the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to:  
>>> Send administrative queries to  
>>>
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email] <mailto:[hidden email]>
>> Official list archives available at http://www.lassotalk.com <http://www.lassotalk.com/>
>> To unsubscribe, E-mail to: <[hidden email] <mailto:[hidden email]>>
>> Send administrative queries to  <[hidden email] <mailto:[hidden email]>>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Tim Taplin
Just reviewing this and thinking that I might need to explain better to see if this matches your need:

in your scenario, step one’s search is to see whether any of several elements would conflict with the new record. Scheduling on a calendar…

Not sure whether you could create a unique key that would allow for simplifying this search. There could be issues with multiple slots on the schedule.

So, I’d propose using a compound statement with builtin conditionals to run the insert statement only if there is no conflict, returning either the last_inserted_id() or a -1 depending on whether the insert took place.

I havent looked up the exact syntax to do this outside a stored procedure, but it would be something like:

if( search query that returns true when slot is available, (insert statement), -1); select last_insert_id() as lastID;

you will need to inspect the two result sets to see the result of the first statement and then grab the lastID value if the insert was successful.

Tim Taplin

> On Nov 27, 2014, at 9:04 AM, Tim Taplin <[hidden email]> wrote:
>
> there is a feature in sql that allows for an insert to check for duplicate key. on duplicate key update
>
> so, assuming that your search step one is to determine whether the record already exists, make sure there is a unique index available, and then do something like:
>
> Insert creating ID on duplicate key update set any values that need updating (set some column = itself if you dont need to update anything )
> get last_insert_id()
>
> not sure when you would need to delete the record with this id since you checked to make sure it wasnt there.
> Probably need more info on the structure of the data here.
>
> TIm Taplin
>
>> On Nov 27, 2014, at 8:57 AM, deco rior <[hidden email]> wrote:
>>
>> We have to worry about concurrency. That is, an insert occurring between the select.
>>
>> For example:
>>
>> 1.Select to see if I can insert A.
>> 2.B gets inserted
>> 3. Insert A based on the result of 1.
>>
>> But B would violate 1.
>>
>> We have bene looking at last_insert_id() but I am not sure if that really helps us here. A final select does the job
>>
>> 4. Select to see if I inserted A first
>>
>> So there a minimum of THREE insert statements that are needed. So I want to avoid three RTT and make it one.
>>
>> Deco
>>
>>
>>
>>
>>
>>
>>> On Nov 27, 2014, at 8:35 AM, Brad Lindsay <[hidden email]> wrote:
>>>
>>> Is it imperative that you don’t use Lasso? Must it all be in SQL?
>>>
>>> Brad
>>>
>>> On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email] <mailto:[hidden email]>) wrote:
>>>> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>>>>
>>>> 1. DO a search
>>>> 2. If no search results then insert (create ID)
>>>> 3. Redo the search
>>>> 4. IF ID not found n the search then delete record with the ID
>>>>
>>>> Does anyone have any pseudocode suggestions for mySQL
>>>>
>>>> Deco
>>>>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>> the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to:  
>>>> Send administrative queries to  
>>>>
>>>
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>> the mailing list Lasso [hidden email] <mailto:[hidden email]>
>>> Official list archives available at http://www.lassotalk.com <http://www.lassotalk.com/>
>>> To unsubscribe, E-mail to: <[hidden email] <mailto:[hidden email]>>
>>> Send administrative queries to  <[hidden email] <mailto:[hidden email]>>
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
Thanks, Tim.

Exactly!

The question I have is whether the last_insert_id() will do the trick.

If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”

Is a stored procedure defined as one connection?


> On Nov 27, 2014, at 9:15 AM, Tim Taplin <[hidden email]> wrote:
>
> Just reviewing this and thinking that I might need to explain better to see if this matches your need:
>
> in your scenario, step one’s search is to see whether any of several elements would conflict with the new record. Scheduling on a calendar…
>
> Not sure whether you could create a unique key that would allow for simplifying this search. There could be issues with multiple slots on the schedule.
>
> So, I’d propose using a compound statement with builtin conditionals to run the insert statement only if there is no conflict, returning either the last_inserted_id() or a -1 depending on whether the insert took place.
>
> I havent looked up the exact syntax to do this outside a stored procedure, but it would be something like:
>
> if( search query that returns true when slot is available, (insert statement), -1); select last_insert_id() as lastID;
>
> you will need to inspect the two result sets to see the result of the first statement and then grab the lastID value if the insert was successful.
>
> Tim Taplin
>
>> On Nov 27, 2014, at 9:04 AM, Tim Taplin <[hidden email]> wrote:
>>
>> there is a feature in sql that allows for an insert to check for duplicate key. on duplicate key update
>>
>> so, assuming that your search step one is to determine whether the record already exists, make sure there is a unique index available, and then do something like:
>>
>> Insert creating ID on duplicate key update set any values that need updating (set some column = itself if you dont need to update anything )
>> get last_insert_id()
>>
>> not sure when you would need to delete the record with this id since you checked to make sure it wasnt there.
>> Probably need more info on the structure of the data here.
>>
>> TIm Taplin
>>
>>> On Nov 27, 2014, at 8:57 AM, deco rior <[hidden email]> wrote:
>>>
>>> We have to worry about concurrency. That is, an insert occurring between the select.
>>>
>>> For example:
>>>
>>> 1.Select to see if I can insert A.
>>> 2.B gets inserted
>>> 3. Insert A based on the result of 1.
>>>
>>> But B would violate 1.
>>>
>>> We have bene looking at last_insert_id() but I am not sure if that really helps us here. A final select does the job
>>>
>>> 4. Select to see if I inserted A first
>>>
>>> So there a minimum of THREE insert statements that are needed. So I want to avoid three RTT and make it one.
>>>
>>> Deco
>>>
>>>
>>>
>>>
>>>
>>>
>>>> On Nov 27, 2014, at 8:35 AM, Brad Lindsay <[hidden email]> wrote:
>>>>
>>>> Is it imperative that you don’t use Lasso? Must it all be in SQL?
>>>>
>>>> Brad
>>>>
>>>> On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email] <mailto:[hidden email]>) wrote:
>>>>> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>>>>>
>>>>> 1. DO a search
>>>>> 2. If no search results then insert (create ID)
>>>>> 3. Redo the search
>>>>> 4. IF ID not found n the search then delete record with the ID
>>>>>
>>>>> Does anyone have any pseudocode suggestions for mySQL
>>>>>
>>>>> Deco
>>>>>
>>>>> #############################################################
>>>>>
>>>>> This message is sent to you because you are subscribed to
>>>>> the mailing list Lasso [hidden email]
>>>>> Official list archives available at http://www.lassotalk.com
>>>>> To unsubscribe, E-mail to:  
>>>>> Send administrative queries to  
>>>>>
>>>>
>>>>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>> the mailing list Lasso [hidden email] <mailto:[hidden email]>
>>>> Official list archives available at http://www.lassotalk.com <http://www.lassotalk.com/>
>>>> To unsubscribe, E-mail to: <[hidden email] <mailto:[hidden email]>>
>>>> Send administrative queries to  <[hidden email] <mailto:[hidden email]>>
>>>
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>> the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Jonathan Guthrie-3
What about using table locks?

> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>
> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”

Jono

----------------------------
Jonathan Guthrie
[hidden email]
@iamjono
LassoSoft Inc.
AIM Chatroom: lassochat


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Jonathan Guthrie-3
Docs:
https://dev.mysql.com/doc/refman/5.6/en/lock-tables.html

The transaction sounds like it will be quick but you're concerned about the edge case, so a lock might be an option.


> On Nov 27, 2014, at 11:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>
> What about using table locks?
>
>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>
>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”

Jono

----------------------------
Jonathan Guthrie
[hidden email]
@iamjono
LassoSoft Inc.
AIM Chatroom: lassochat


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
In reply to this post by Jonathan Guthrie-3
Thanks. Yes, I thought about this.

The majority of inserts are non-blocking i.e. they do not cause a conflict.


Let me explain.


I am booking a court time on a court.

I receive two requests

1. 8AM on court 1
2. 8AM on court 2

No need to lock here because they can occur ay “same” time

1. 8AM on Court 1
2. 8AM on Court 1

The second one has to fail :-)




> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>
> What about using table locks?
>
>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>
>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>
> Jono
>
> ----------------------------
> Jonathan Guthrie
> [hidden email]
> @iamjono
> LassoSoft Inc.
> AIM Chatroom: lassochat
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Tim Taplin
In reply to this post by decorior
when you send multiple queries in one request, they are executed as one connection thread. So, the last_insert_id() will return the id of the last record created in your current set of requests.

Tim

> On Nov 27, 2014, at 9:22 AM, deco rior <[hidden email]> wrote:
>
> Thanks, Tim.
>
> Exactly!
>
> The question I have is whether the last_insert_id() will do the trick.
>
> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>
> Is a stored procedure defined as one connection?
>
>
>> On Nov 27, 2014, at 9:15 AM, Tim Taplin <[hidden email]> wrote:
>>
>> Just reviewing this and thinking that I might need to explain better to see if this matches your need:
>>
>> in your scenario, step one’s search is to see whether any of several elements would conflict with the new record. Scheduling on a calendar…
>>
>> Not sure whether you could create a unique key that would allow for simplifying this search. There could be issues with multiple slots on the schedule.
>>
>> So, I’d propose using a compound statement with builtin conditionals to run the insert statement only if there is no conflict, returning either the last_inserted_id() or a -1 depending on whether the insert took place.
>>
>> I havent looked up the exact syntax to do this outside a stored procedure, but it would be something like:
>>
>> if( search query that returns true when slot is available, (insert statement), -1); select last_insert_id() as lastID;
>>
>> you will need to inspect the two result sets to see the result of the first statement and then grab the lastID value if the insert was successful.
>>
>> Tim Taplin
>>
>>> On Nov 27, 2014, at 9:04 AM, Tim Taplin <[hidden email]> wrote:
>>>
>>> there is a feature in sql that allows for an insert to check for duplicate key. on duplicate key update
>>>
>>> so, assuming that your search step one is to determine whether the record already exists, make sure there is a unique index available, and then do something like:
>>>
>>> Insert creating ID on duplicate key update set any values that need updating (set some column = itself if you dont need to update anything )
>>> get last_insert_id()
>>>
>>> not sure when you would need to delete the record with this id since you checked to make sure it wasnt there.
>>> Probably need more info on the structure of the data here.
>>>
>>> TIm Taplin
>>>
>>>> On Nov 27, 2014, at 8:57 AM, deco rior <[hidden email]> wrote:
>>>>
>>>> We have to worry about concurrency. That is, an insert occurring between the select.
>>>>
>>>> For example:
>>>>
>>>> 1.Select to see if I can insert A.
>>>> 2.B gets inserted
>>>> 3. Insert A based on the result of 1.
>>>>
>>>> But B would violate 1.
>>>>
>>>> We have bene looking at last_insert_id() but I am not sure if that really helps us here. A final select does the job
>>>>
>>>> 4. Select to see if I inserted A first
>>>>
>>>> So there a minimum of THREE insert statements that are needed. So I want to avoid three RTT and make it one.
>>>>
>>>> Deco
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Nov 27, 2014, at 8:35 AM, Brad Lindsay <[hidden email]> wrote:
>>>>>
>>>>> Is it imperative that you don’t use Lasso? Must it all be in SQL?
>>>>>
>>>>> Brad
>>>>>
>>>>> On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email] <mailto:[hidden email]>) wrote:
>>>>>> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>>>>>>
>>>>>> 1. DO a search
>>>>>> 2. If no search results then insert (create ID)
>>>>>> 3. Redo the search
>>>>>> 4. IF ID not found n the search then delete record with the ID
>>>>>>
>>>>>> Does anyone have any pseudocode suggestions for mySQL
>>>>>>
>>>>>> Deco
>>>>>>
>>>>>> #############################################################
>>>>>>
>>>>>> This message is sent to you because you are subscribed to
>>>>>> the mailing list Lasso [hidden email]
>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>> To unsubscribe, E-mail to:  
>>>>>> Send administrative queries to  
>>>>>>
>>>>>
>>>>>
>>>>> #############################################################
>>>>>
>>>>> This message is sent to you because you are subscribed to
>>>>> the mailing list Lasso [hidden email] <mailto:[hidden email]>
>>>>> Official list archives available at http://www.lassotalk.com <http://www.lassotalk.com/>
>>>>> To unsubscribe, E-mail to: <[hidden email] <mailto:[hidden email]>>
>>>>> Send administrative queries to  <[hidden email] <mailto:[hidden email]>>
>>>>
>>>>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>> the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>> Send administrative queries to  <[hidden email]>
>>>
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>> the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
In reply to this post by Jonathan Guthrie-3
Yes, unfortunately not much of an edge case in my case :-(

> On Nov 27, 2014, at 9:28 AM, Jonathan Guthrie <[hidden email]> wrote:
>
> Docs:
> https://dev.mysql.com/doc/refman/5.6/en/lock-tables.html
>
> The transaction sounds like it will be quick but you're concerned about the edge case, so a lock might be an option.
>
>
>> On Nov 27, 2014, at 11:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>
>> What about using table locks?
>>
>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>
>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>
> Jono
>
> ----------------------------
> Jonathan Guthrie
> [hidden email]
> @iamjono
> LassoSoft Inc.
> AIM Chatroom: lassochat
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
In reply to this post by Tim Taplin
Awesome.

So putting all the requests into one sql statement or stored procedure is the way to go!


> On Nov 27, 2014, at 9:29 AM, Tim Taplin <[hidden email]> wrote:
>
> when you send multiple queries in one request, they are executed as one connection thread. So, the last_insert_id() will return the id of the last record created in your current set of requests.
>
> Tim
>
>> On Nov 27, 2014, at 9:22 AM, deco rior <[hidden email]> wrote:
>>
>> Thanks, Tim.
>>
>> Exactly!
>>
>> The question I have is whether the last_insert_id() will do the trick.
>>
>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>>
>> Is a stored procedure defined as one connection?
>>
>>
>>> On Nov 27, 2014, at 9:15 AM, Tim Taplin <[hidden email]> wrote:
>>>
>>> Just reviewing this and thinking that I might need to explain better to see if this matches your need:
>>>
>>> in your scenario, step one’s search is to see whether any of several elements would conflict with the new record. Scheduling on a calendar…
>>>
>>> Not sure whether you could create a unique key that would allow for simplifying this search. There could be issues with multiple slots on the schedule.
>>>
>>> So, I’d propose using a compound statement with builtin conditionals to run the insert statement only if there is no conflict, returning either the last_inserted_id() or a -1 depending on whether the insert took place.
>>>
>>> I havent looked up the exact syntax to do this outside a stored procedure, but it would be something like:
>>>
>>> if( search query that returns true when slot is available, (insert statement), -1); select last_insert_id() as lastID;
>>>
>>> you will need to inspect the two result sets to see the result of the first statement and then grab the lastID value if the insert was successful.
>>>
>>> Tim Taplin
>>>
>>>> On Nov 27, 2014, at 9:04 AM, Tim Taplin <[hidden email]> wrote:
>>>>
>>>> there is a feature in sql that allows for an insert to check for duplicate key. on duplicate key update
>>>>
>>>> so, assuming that your search step one is to determine whether the record already exists, make sure there is a unique index available, and then do something like:
>>>>
>>>> Insert creating ID on duplicate key update set any values that need updating (set some column = itself if you dont need to update anything )
>>>> get last_insert_id()
>>>>
>>>> not sure when you would need to delete the record with this id since you checked to make sure it wasnt there.
>>>> Probably need more info on the structure of the data here.
>>>>
>>>> TIm Taplin
>>>>
>>>>> On Nov 27, 2014, at 8:57 AM, deco rior <[hidden email]> wrote:
>>>>>
>>>>> We have to worry about concurrency. That is, an insert occurring between the select.
>>>>>
>>>>> For example:
>>>>>
>>>>> 1.Select to see if I can insert A.
>>>>> 2.B gets inserted
>>>>> 3. Insert A based on the result of 1.
>>>>>
>>>>> But B would violate 1.
>>>>>
>>>>> We have bene looking at last_insert_id() but I am not sure if that really helps us here. A final select does the job
>>>>>
>>>>> 4. Select to see if I inserted A first
>>>>>
>>>>> So there a minimum of THREE insert statements that are needed. So I want to avoid three RTT and make it one.
>>>>>
>>>>> Deco
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Nov 27, 2014, at 8:35 AM, Brad Lindsay <[hidden email]> wrote:
>>>>>>
>>>>>> Is it imperative that you don’t use Lasso? Must it all be in SQL?
>>>>>>
>>>>>> Brad
>>>>>>
>>>>>> On November 27, 2014 at 9:58:27 AM, deco rior ([hidden email] <mailto:[hidden email]>) wrote:
>>>>>>> I wanted to write the following multi-statement SQL query. It needs to do the following.  
>>>>>>>
>>>>>>> 1. DO a search
>>>>>>> 2. If no search results then insert (create ID)
>>>>>>> 3. Redo the search
>>>>>>> 4. IF ID not found n the search then delete record with the ID
>>>>>>>
>>>>>>> Does anyone have any pseudocode suggestions for mySQL
>>>>>>>
>>>>>>> Deco
>>>>>>>
>>>>>>> #############################################################
>>>>>>>
>>>>>>> This message is sent to you because you are subscribed to
>>>>>>> the mailing list Lasso [hidden email]
>>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>>> To unsubscribe, E-mail to:  
>>>>>>> Send administrative queries to  
>>>>>>>
>>>>>>
>>>>>>
>>>>>> #############################################################
>>>>>>
>>>>>> This message is sent to you because you are subscribed to
>>>>>> the mailing list Lasso [hidden email] <mailto:[hidden email]>
>>>>>> Official list archives available at http://www.lassotalk.com <http://www.lassotalk.com/>
>>>>>> To unsubscribe, E-mail to: <[hidden email] <mailto:[hidden email]>>
>>>>>> Send administrative queries to  <[hidden email] <mailto:[hidden email]>>
>>>>>
>>>>>
>>>>> #############################################################
>>>>>
>>>>> This message is sent to you because you are subscribed to
>>>>> the mailing list Lasso [hidden email]
>>>>> Official list archives available at http://www.lassotalk.com
>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>> Send administrative queries to  <[hidden email]>
>>>>
>>>>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>> the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>> Send administrative queries to  <[hidden email]>
>>>
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>> the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>  the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Trevor Borgmeier
In reply to this post by decorior
Couldn't you just setup your table so that the combination of datetime
and location need to be unique.  Then, if they are not unique #2 would
fail...

CREATE TABLE court_schedule
`location_id` ...
`datetime` ...
UNIQUE KEY `time_space` (`location_id`,`datetime`);

-Trevor


On 11/27/14 10:29 AM, deco rior wrote:

> Thanks. Yes, I thought about this.
>
> The majority of inserts are non-blocking i.e. they do not cause a conflict.
>
>
> Let me explain.
>
>
> I am booking a court time on a court.
>
> I receive two requests
>
> 1. 8AM on court 1
> 2. 8AM on court 2
>
> No need to lock here because they can occur ay “same” time
>
> 1. 8AM on Court 1
> 2. 8AM on Court 1
>
> The second one has to fail :-)
>
>
>
>
>> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>
>> What about using table locks?
>>
>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>
>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>> Jono
>>
>> ----------------------------
>> Jonathan Guthrie
>> [hidden email]
>> @iamjono
>> LassoSoft Inc.
>> AIM Chatroom: lassochat
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>>   the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>    the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


ɹǝıǝɯƃɹoq ɹoʌǝɹʇ


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Tim Taplin
If the key could be created, then an on duplicate key update could be used to easily perform the insert properly, but imagine that 1 is for two hours and two is for one hour, or that one starts at 830 and two starts at 8 am. In the scheduling scenario, the initial search has to handle overlapping timeframes and not just search for the precise time slot and location. Therefore, I have assumed that a unique key does not handle the initial query statement.

Tim

> On Nov 27, 2014, at 9:49 AM, Trevor Borgmeier <[hidden email]> wrote:
>
> Couldn't you just setup your table so that the combination of datetime and location need to be unique.  Then, if they are not unique #2 would fail...
>
> CREATE TABLE court_schedule
> `location_id` ...
> `datetime` ...
> UNIQUE KEY `time_space` (`location_id`,`datetime`);
>
> -Trevor
>
>
> On 11/27/14 10:29 AM, deco rior wrote:
>> Thanks. Yes, I thought about this.
>>
>> The majority of inserts are non-blocking i.e. they do not cause a conflict.
>>
>>
>> Let me explain.
>>
>>
>> I am booking a court time on a court.
>>
>> I receive two requests
>>
>> 1. 8AM on court 1
>> 2. 8AM on court 2
>>
>> No need to lock here because they can occur ay “same” time
>>
>> 1. 8AM on Court 1
>> 2. 8AM on Court 1
>>
>> The second one has to fail :-)
>>
>>
>>
>>
>>> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>>
>>> What about using table locks?
>>>
>>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>>
>>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>>> Jono
>>>
>>> ----------------------------
>>> Jonathan Guthrie
>>> [hidden email]
>>> @iamjono
>>> LassoSoft Inc.
>>> AIM Chatroom: lassochat
>>>
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>>  the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>>   the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
>
> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
> the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Trevor Borgmeier
Yes, if durations vary then this wouldn't work...

-Trevor


On 11/27/14 10:54 AM, Tim Taplin wrote:

> If the key could be created, then an on duplicate key update could be used to easily perform the insert properly, but imagine that 1 is for two hours and two is for one hour, or that one starts at 830 and two starts at 8 am. In the scheduling scenario, the initial search has to handle overlapping timeframes and not just search for the precise time slot and location. Therefore, I have assumed that a unique key does not handle the initial query statement.
>
> Tim
>
>> On Nov 27, 2014, at 9:49 AM, Trevor Borgmeier <[hidden email]> wrote:
>>
>> Couldn't you just setup your table so that the combination of datetime and location need to be unique.  Then, if they are not unique #2 would fail...
>>
>> CREATE TABLE court_schedule
>> `location_id` ...
>> `datetime` ...
>> UNIQUE KEY `time_space` (`location_id`,`datetime`);
>>
>> -Trevor
>>
>>
>> On 11/27/14 10:29 AM, deco rior wrote:
>>> Thanks. Yes, I thought about this.
>>>
>>> The majority of inserts are non-blocking i.e. they do not cause a conflict.
>>>
>>>
>>> Let me explain.
>>>
>>>
>>> I am booking a court time on a court.
>>>
>>> I receive two requests
>>>
>>> 1. 8AM on court 1
>>> 2. 8AM on court 2
>>>
>>> No need to lock here because they can occur ay “same” time
>>>
>>> 1. 8AM on Court 1
>>> 2. 8AM on Court 1
>>>
>>> The second one has to fail :-)
>>>
>>>
>>>
>>>
>>>> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>>>
>>>> What about using table locks?
>>>>
>>>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>>>
>>>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>>>> Jono
>>>>
>>>> ----------------------------
>>>> Jonathan Guthrie
>>>> [hidden email]
>>>> @iamjono
>>>> LassoSoft Inc.
>>>> AIM Chatroom: lassochat
>>>>
>>>>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>>   the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>> Send administrative queries to  <[hidden email]>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>>    the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>    the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>



#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
Yes, but we have some cases like that.

Deco

> On Nov 27, 2014, at 10:05 AM, Trevor Borgmeier <[hidden email]> wrote:
>
> Yes, if durations vary then this wouldn't work...
>
> -Trevor
>
>
> On 11/27/14 10:54 AM, Tim Taplin wrote:
>> If the key could be created, then an on duplicate key update could be used to easily perform the insert properly, but imagine that 1 is for two hours and two is for one hour, or that one starts at 830 and two starts at 8 am. In the scheduling scenario, the initial search has to handle overlapping timeframes and not just search for the precise time slot and location. Therefore, I have assumed that a unique key does not handle the initial query statement.
>>
>> Tim
>>
>>> On Nov 27, 2014, at 9:49 AM, Trevor Borgmeier <[hidden email]> wrote:
>>>
>>> Couldn't you just setup your table so that the combination of datetime and location need to be unique.  Then, if they are not unique #2 would fail...
>>>
>>> CREATE TABLE court_schedule
>>> `location_id` ...
>>> `datetime` ...
>>> UNIQUE KEY `time_space` (`location_id`,`datetime`);
>>>
>>> -Trevor
>>>
>>>
>>> On 11/27/14 10:29 AM, deco rior wrote:
>>>> Thanks. Yes, I thought about this.
>>>>
>>>> The majority of inserts are non-blocking i.e. they do not cause a conflict.
>>>>
>>>>
>>>> Let me explain.
>>>>
>>>>
>>>> I am booking a court time on a court.
>>>>
>>>> I receive two requests
>>>>
>>>> 1. 8AM on court 1
>>>> 2. 8AM on court 2
>>>>
>>>> No need to lock here because they can occur ay “same” time
>>>>
>>>> 1. 8AM on Court 1
>>>> 2. 8AM on Court 1
>>>>
>>>> The second one has to fail :-)
>>>>
>>>>
>>>>
>>>>
>>>>> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>>>>
>>>>> What about using table locks?
>>>>>
>>>>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>>>>
>>>>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>>>>> Jono
>>>>>
>>>>> ----------------------------
>>>>> Jonathan Guthrie
>>>>> [hidden email]
>>>>> @iamjono
>>>>> LassoSoft Inc.
>>>>> AIM Chatroom: lassochat
>>>>>
>>>>>
>>>>> #############################################################
>>>>>
>>>>> This message is sent to you because you are subscribed to
>>>>>  the mailing list Lasso [hidden email]
>>>>> Official list archives available at http://www.lassotalk.com
>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>> Send administrative queries to  <[hidden email]>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>>   the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>> Send administrative queries to  <[hidden email]>
>>>
>>> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>>>
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>> the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>>   the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
> the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Trevor Borgmeier
Here is my new answer...

Table setup...

CREATE TABLE `schedule` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
   `location_id` int(4) DEFAULT '0',
   `datetime_start` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
   `datetime_end` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
   PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;


records to get started...
INSERT INTO schedule (location_id, datetime_start, datetime_end) VALUES
(1,'2014-11-12 08:00:00','2014-11-12 10:00:00'),
(1,'2014-11-12 10:30:00','2014-11-12 13:00:00'),
(1,'2014-11-12 13:00:00','2014-11-12 14:00:00'),
(1,'2014-11-12 14:00:00','2014-11-12 14:30:00');


Below are various test inserts to demonstrate successes and failures as
expected.

-- INSERT VIA SELECT(S) ... THIS SHOULD FAIL...
SET @location_id:='1', @datetime_start:='2014-11-12 08:15:00',
@datetime_end:='2014-11-12 09:00:00';
INSERT INTO schedule
(location_id, datetime_start, datetime_end)
     SELECT @location_id, @datetime_start, @datetime_end
     FROM schedule
     WHERE not exists (
         SELECT * FROM schedule
         WHERE
             location_id = @location_id
             && (
                 (@datetime_start >= datetime_start AND @datetime_start
< datetime_end)
                 || (@datetime_end > datetime_start AND @datetime_end <=
datetime_end)
             )
         ) LIMIT 1;


-- INSERT VIA SELECT(S) ... THIS SHOULD FAIL...
SET @location_id:='1', @datetime_start:='2014-11-12 07:00:00',
@datetime_end:='2014-11-12 10:30:00';
INSERT INTO schedule
(location_id, datetime_start, datetime_end)
     SELECT @location_id, @datetime_start, @datetime_end
     FROM schedule
     WHERE not exists (
         SELECT * FROM schedule
         WHERE
             location_id = @location_id
             && (
                 (@datetime_start >= datetime_start AND @datetime_start
< datetime_end)
                 || (@datetime_end > datetime_start AND @datetime_end <=
datetime_end)
             )
         ) LIMIT 1;


-- INSERT VIA SELECT(S) ... THIS SHOULD INSERT A RECORD...
SET @location_id:='1', @datetime_start:='2014-11-12 10:00:00',
@datetime_end:='2014-11-12 10:30:00';
INSERT INTO schedule
(location_id, datetime_start, datetime_end)
     SELECT @location_id, @datetime_start, @datetime_end
     FROM schedule
     WHERE not exists (
         SELECT * FROM schedule
         WHERE
             location_id = @location_id
             && (
                 (@datetime_start >= datetime_start AND @datetime_start
< datetime_end)
                 || (@datetime_end > datetime_start AND @datetime_end <=
datetime_end)
             )
         ) LIMIT 1;

You should be able to check affected rows to determine success or failure...




On 11/27/14 11:10 AM, deco rior wrote:

> Yes, but we have some cases like that.
>
> Deco
>> On Nov 27, 2014, at 10:05 AM, Trevor Borgmeier <[hidden email]> wrote:
>>
>> Yes, if durations vary then this wouldn't work...
>>
>> -Trevor
>>
>>
>> On 11/27/14 10:54 AM, Tim Taplin wrote:
>>> If the key could be created, then an on duplicate key update could be used to easily perform the insert properly, but imagine that 1 is for two hours and two is for one hour, or that one starts at 830 and two starts at 8 am. In the scheduling scenario, the initial search has to handle overlapping timeframes and not just search for the precise time slot and location. Therefore, I have assumed that a unique key does not handle the initial query statement.
>>>
>>> Tim
>>>
>>>> On Nov 27, 2014, at 9:49 AM, Trevor Borgmeier <[hidden email]> wrote:
>>>>
>>>> Couldn't you just setup your table so that the combination of datetime and location need to be unique.  Then, if they are not unique #2 would fail...
>>>>
>>>> CREATE TABLE court_schedule
>>>> `location_id` ...
>>>> `datetime` ...
>>>> UNIQUE KEY `time_space` (`location_id`,`datetime`);
>>>>
>>>> -Trevor
>>>>
>>>>
>>>> On 11/27/14 10:29 AM, deco rior wrote:
>>>>> Thanks. Yes, I thought about this.
>>>>>
>>>>> The majority of inserts are non-blocking i.e. they do not cause a conflict.
>>>>>
>>>>>
>>>>> Let me explain.
>>>>>
>>>>>
>>>>> I am booking a court time on a court.
>>>>>
>>>>> I receive two requests
>>>>>
>>>>> 1. 8AM on court 1
>>>>> 2. 8AM on court 2
>>>>>
>>>>> No need to lock here because they can occur ay “same” time
>>>>>
>>>>> 1. 8AM on Court 1
>>>>> 2. 8AM on Court 1
>>>>>
>>>>> The second one has to fail :-)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>>>>>
>>>>>> What about using table locks?
>>>>>>
>>>>>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>>>>>
>>>>>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>>>>>> Jono
>>>>>>
>>>>>> ----------------------------
>>>>>> Jonathan Guthrie
>>>>>> [hidden email]
>>>>>> @iamjono
>>>>>> LassoSoft Inc.
>>>>>> AIM Chatroom: lassochat
>>>>>>
>>>>>>
>>>>>> #############################################################
>>>>>>
>>>>>> This message is sent to you because you are subscribed to
>>>>>>   the mailing list Lasso [hidden email]
>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>>> Send administrative queries to  <[hidden email]>
>>>>> #############################################################
>>>>>
>>>>> This message is sent to you because you are subscribed to
>>>>>    the mailing list Lasso [hidden email]
>>>>> Official list archives available at http://www.lassotalk.com
>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>> Send administrative queries to  <[hidden email]>
>>>> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>>>>
>>>>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>> the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>> Send administrative queries to  <[hidden email]>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>>    the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>    the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


ɹǝıǝɯƃɹoq ɹoʌǝɹʇ


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

decorior
Thanks, Trevor:

My question is if two identical requests occur at the same time, then I think this fails, hence the second select is needed



> On Nov 27, 2014, at 11:34 AM, Trevor Borgmeier <[hidden email]> wrote:
>
> Here is my new answer...
>
> Table setup...
>
> CREATE TABLE `schedule` (
> `id` bigint(20) NOT NULL AUTO_INCREMENT,
>  `location_id` int(4) DEFAULT '0',
>  `datetime_start` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
>  `datetime_end` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
>  PRIMARY KEY (`id`)
> ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
>
>
> records to get started...
> INSERT INTO schedule (location_id, datetime_start, datetime_end) VALUES
> (1,'2014-11-12 08:00:00','2014-11-12 10:00:00'),
> (1,'2014-11-12 10:30:00','2014-11-12 13:00:00'),
> (1,'2014-11-12 13:00:00','2014-11-12 14:00:00'),
> (1,'2014-11-12 14:00:00','2014-11-12 14:30:00');
>
>
> Below are various test inserts to demonstrate successes and failures as expected.
>
> -- INSERT VIA SELECT(S) ... THIS SHOULD FAIL...
> SET @location_id:='1', @datetime_start:='2014-11-12 08:15:00', @datetime_end:='2014-11-12 09:00:00';
> INSERT INTO schedule
> (location_id, datetime_start, datetime_end)
>    SELECT @location_id, @datetime_start, @datetime_end
>    FROM schedule
>    WHERE not exists (
>        SELECT * FROM schedule
>        WHERE
>            location_id = @location_id
>            && (
>                (@datetime_start >= datetime_start AND @datetime_start < datetime_end)
>                || (@datetime_end > datetime_start AND @datetime_end <= datetime_end)
>            )
>        ) LIMIT 1;
>
>
> -- INSERT VIA SELECT(S) ... THIS SHOULD FAIL...
> SET @location_id:='1', @datetime_start:='2014-11-12 07:00:00', @datetime_end:='2014-11-12 10:30:00';
> INSERT INTO schedule
> (location_id, datetime_start, datetime_end)
>    SELECT @location_id, @datetime_start, @datetime_end
>    FROM schedule
>    WHERE not exists (
>        SELECT * FROM schedule
>        WHERE
>            location_id = @location_id
>            && (
>                (@datetime_start >= datetime_start AND @datetime_start < datetime_end)
>                || (@datetime_end > datetime_start AND @datetime_end <= datetime_end)
>            )
>        ) LIMIT 1;
>
>
> -- INSERT VIA SELECT(S) ... THIS SHOULD INSERT A RECORD...
> SET @location_id:='1', @datetime_start:='2014-11-12 10:00:00', @datetime_end:='2014-11-12 10:30:00';
> INSERT INTO schedule
> (location_id, datetime_start, datetime_end)
>    SELECT @location_id, @datetime_start, @datetime_end
>    FROM schedule
>    WHERE not exists (
>        SELECT * FROM schedule
>        WHERE
>            location_id = @location_id
>            && (
>                (@datetime_start >= datetime_start AND @datetime_start < datetime_end)
>                || (@datetime_end > datetime_start AND @datetime_end <= datetime_end)
>            )
>        ) LIMIT 1;
>
> You should be able to check affected rows to determine success or failure...
>
>
>
>
> On 11/27/14 11:10 AM, deco rior wrote:
>> Yes, but we have some cases like that.
>>
>> Deco
>>> On Nov 27, 2014, at 10:05 AM, Trevor Borgmeier <[hidden email]> wrote:
>>>
>>> Yes, if durations vary then this wouldn't work...
>>>
>>> -Trevor
>>>
>>>
>>> On 11/27/14 10:54 AM, Tim Taplin wrote:
>>>> If the key could be created, then an on duplicate key update could be used to easily perform the insert properly, but imagine that 1 is for two hours and two is for one hour, or that one starts at 830 and two starts at 8 am. In the scheduling scenario, the initial search has to handle overlapping timeframes and not just search for the precise time slot and location. Therefore, I have assumed that a unique key does not handle the initial query statement.
>>>>
>>>> Tim
>>>>
>>>>> On Nov 27, 2014, at 9:49 AM, Trevor Borgmeier <[hidden email]> wrote:
>>>>>
>>>>> Couldn't you just setup your table so that the combination of datetime and location need to be unique.  Then, if they are not unique #2 would fail...
>>>>>
>>>>> CREATE TABLE court_schedule
>>>>> `location_id` ...
>>>>> `datetime` ...
>>>>> UNIQUE KEY `time_space` (`location_id`,`datetime`);
>>>>>
>>>>> -Trevor
>>>>>
>>>>>
>>>>> On 11/27/14 10:29 AM, deco rior wrote:
>>>>>> Thanks. Yes, I thought about this.
>>>>>>
>>>>>> The majority of inserts are non-blocking i.e. they do not cause a conflict.
>>>>>>
>>>>>>
>>>>>> Let me explain.
>>>>>>
>>>>>>
>>>>>> I am booking a court time on a court.
>>>>>>
>>>>>> I receive two requests
>>>>>>
>>>>>> 1. 8AM on court 1
>>>>>> 2. 8AM on court 2
>>>>>>
>>>>>> No need to lock here because they can occur ay “same” time
>>>>>>
>>>>>> 1. 8AM on Court 1
>>>>>> 2. 8AM on Court 1
>>>>>>
>>>>>> The second one has to fail :-)
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>>>>>>
>>>>>>> What about using table locks?
>>>>>>>
>>>>>>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>>>>>>> Jono
>>>>>>>
>>>>>>> ----------------------------
>>>>>>> Jonathan Guthrie
>>>>>>> [hidden email]
>>>>>>> @iamjono
>>>>>>> LassoSoft Inc.
>>>>>>> AIM Chatroom: lassochat
>>>>>>>
>>>>>>>
>>>>>>> #############################################################
>>>>>>>
>>>>>>> This message is sent to you because you are subscribed to
>>>>>>>  the mailing list Lasso [hidden email]
>>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>>>> Send administrative queries to  <[hidden email]>
>>>>>> #############################################################
>>>>>>
>>>>>> This message is sent to you because you are subscribed to
>>>>>>   the mailing list Lasso [hidden email]
>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>>> Send administrative queries to  <[hidden email]>
>>>>> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>>>>>
>>>>>
>>>>> #############################################################
>>>>>
>>>>> This message is sent to you because you are subscribed to
>>>>> the mailing list Lasso [hidden email]
>>>>> Official list archives available at http://www.lassotalk.com
>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>> Send administrative queries to  <[hidden email]>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>>   the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>> Send administrative queries to  <[hidden email]>
>>>
>>>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>> the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>>   the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
>
> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
> the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
Reply | Threaded
Open this post in threaded view
|

Re: Suggested query

Trevor Borgmeier
The first select is really just a sort of dummy select used to pass the
values you want to insert into the table but allowing it be dependent on
the results of the second select.
The second select is doing the work of checking for scheduling conflicts.

I used MySQL variables just to make it easier to test so I didn't need
to retype the date/times multiple times in each query.

The LIMIT 1 is to prevent it from inserting the same record multiple
times (once for each record that doesn't conflict) This could also be
addressed b using unique keys for location and datetime_start, or
something like that, but the LIMIT 1 is cleaner.

-Trevor



On 11/27/14 12:56 PM, deco rior wrote:

> Thanks, Trevor:
>
> My question is if two identical requests occur at the same time, then I think this fails, hence the second select is needed
>
>
>
>> On Nov 27, 2014, at 11:34 AM, Trevor Borgmeier <[hidden email]> wrote:
>>
>> Here is my new answer...
>>
>> Table setup...
>>
>> CREATE TABLE `schedule` (
>> `id` bigint(20) NOT NULL AUTO_INCREMENT,
>>   `location_id` int(4) DEFAULT '0',
>>   `datetime_start` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
>>   `datetime_end` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
>>   PRIMARY KEY (`id`)
>> ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
>>
>>
>> records to get started...
>> INSERT INTO schedule (location_id, datetime_start, datetime_end) VALUES
>> (1,'2014-11-12 08:00:00','2014-11-12 10:00:00'),
>> (1,'2014-11-12 10:30:00','2014-11-12 13:00:00'),
>> (1,'2014-11-12 13:00:00','2014-11-12 14:00:00'),
>> (1,'2014-11-12 14:00:00','2014-11-12 14:30:00');
>>
>>
>> Below are various test inserts to demonstrate successes and failures as expected.
>>
>> -- INSERT VIA SELECT(S) ... THIS SHOULD FAIL...
>> SET @location_id:='1', @datetime_start:='2014-11-12 08:15:00', @datetime_end:='2014-11-12 09:00:00';
>> INSERT INTO schedule
>> (location_id, datetime_start, datetime_end)
>>     SELECT @location_id, @datetime_start, @datetime_end
>>     FROM schedule
>>     WHERE not exists (
>>         SELECT * FROM schedule
>>         WHERE
>>             location_id = @location_id
>>             && (
>>                 (@datetime_start >= datetime_start AND @datetime_start < datetime_end)
>>                 || (@datetime_end > datetime_start AND @datetime_end <= datetime_end)
>>             )
>>         ) LIMIT 1;
>>
>>
>> -- INSERT VIA SELECT(S) ... THIS SHOULD FAIL...
>> SET @location_id:='1', @datetime_start:='2014-11-12 07:00:00', @datetime_end:='2014-11-12 10:30:00';
>> INSERT INTO schedule
>> (location_id, datetime_start, datetime_end)
>>     SELECT @location_id, @datetime_start, @datetime_end
>>     FROM schedule
>>     WHERE not exists (
>>         SELECT * FROM schedule
>>         WHERE
>>             location_id = @location_id
>>             && (
>>                 (@datetime_start >= datetime_start AND @datetime_start < datetime_end)
>>                 || (@datetime_end > datetime_start AND @datetime_end <= datetime_end)
>>             )
>>         ) LIMIT 1;
>>
>>
>> -- INSERT VIA SELECT(S) ... THIS SHOULD INSERT A RECORD...
>> SET @location_id:='1', @datetime_start:='2014-11-12 10:00:00', @datetime_end:='2014-11-12 10:30:00';
>> INSERT INTO schedule
>> (location_id, datetime_start, datetime_end)
>>     SELECT @location_id, @datetime_start, @datetime_end
>>     FROM schedule
>>     WHERE not exists (
>>         SELECT * FROM schedule
>>         WHERE
>>             location_id = @location_id
>>             && (
>>                 (@datetime_start >= datetime_start AND @datetime_start < datetime_end)
>>                 || (@datetime_end > datetime_start AND @datetime_end <= datetime_end)
>>             )
>>         ) LIMIT 1;
>>
>> You should be able to check affected rows to determine success or failure...
>>
>>
>>
>>
>> On 11/27/14 11:10 AM, deco rior wrote:
>>> Yes, but we have some cases like that.
>>>
>>> Deco
>>>> On Nov 27, 2014, at 10:05 AM, Trevor Borgmeier <[hidden email]> wrote:
>>>>
>>>> Yes, if durations vary then this wouldn't work...
>>>>
>>>> -Trevor
>>>>
>>>>
>>>> On 11/27/14 10:54 AM, Tim Taplin wrote:
>>>>> If the key could be created, then an on duplicate key update could be used to easily perform the insert properly, but imagine that 1 is for two hours and two is for one hour, or that one starts at 830 and two starts at 8 am. In the scheduling scenario, the initial search has to handle overlapping timeframes and not just search for the precise time slot and location. Therefore, I have assumed that a unique key does not handle the initial query statement.
>>>>>
>>>>> Tim
>>>>>
>>>>>> On Nov 27, 2014, at 9:49 AM, Trevor Borgmeier <[hidden email]> wrote:
>>>>>>
>>>>>> Couldn't you just setup your table so that the combination of datetime and location need to be unique.  Then, if they are not unique #2 would fail...
>>>>>>
>>>>>> CREATE TABLE court_schedule
>>>>>> `location_id` ...
>>>>>> `datetime` ...
>>>>>> UNIQUE KEY `time_space` (`location_id`,`datetime`);
>>>>>>
>>>>>> -Trevor
>>>>>>
>>>>>>
>>>>>> On 11/27/14 10:29 AM, deco rior wrote:
>>>>>>> Thanks. Yes, I thought about this.
>>>>>>>
>>>>>>> The majority of inserts are non-blocking i.e. they do not cause a conflict.
>>>>>>>
>>>>>>>
>>>>>>> Let me explain.
>>>>>>>
>>>>>>>
>>>>>>> I am booking a court time on a court.
>>>>>>>
>>>>>>> I receive two requests
>>>>>>>
>>>>>>> 1. 8AM on court 1
>>>>>>> 2. 8AM on court 2
>>>>>>>
>>>>>>> No need to lock here because they can occur ay “same” time
>>>>>>>
>>>>>>> 1. 8AM on Court 1
>>>>>>> 2. 8AM on Court 1
>>>>>>>
>>>>>>> The second one has to fail :-)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Nov 27, 2014, at 9:26 AM, Jonathan Guthrie <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> What about using table locks?
>>>>>>>>
>>>>>>>>> On Nov 27, 2014, at 11:22 AM, deco rior <[hidden email]> wrote:
>>>>>>>>>
>>>>>>>>> If a record gets inserted between the search query and the insert, will it show the one that was inserted by someone else or by that statement? The documentation says it is “per-connection”
>>>>>>>> Jono
>>>>>>>>
>>>>>>>> ----------------------------
>>>>>>>> Jonathan Guthrie
>>>>>>>> [hidden email]
>>>>>>>> @iamjono
>>>>>>>> LassoSoft Inc.
>>>>>>>> AIM Chatroom: lassochat
>>>>>>>>
>>>>>>>>
>>>>>>>> #############################################################
>>>>>>>>
>>>>>>>> This message is sent to you because you are subscribed to
>>>>>>>>   the mailing list Lasso [hidden email]
>>>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>>>>> Send administrative queries to  <[hidden email]>
>>>>>>> #############################################################
>>>>>>>
>>>>>>> This message is sent to you because you are subscribed to
>>>>>>>    the mailing list Lasso [hidden email]
>>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>>>> Send administrative queries to  <[hidden email]>
>>>>>> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>>>>>>
>>>>>>
>>>>>> #############################################################
>>>>>>
>>>>>> This message is sent to you because you are subscribed to
>>>>>> the mailing list Lasso [hidden email]
>>>>>> Official list archives available at http://www.lassotalk.com
>>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>>> Send administrative queries to  <[hidden email]>
>>>>> #############################################################
>>>>>
>>>>> This message is sent to you because you are subscribed to
>>>>>    the mailing list Lasso [hidden email]
>>>>> Official list archives available at http://www.lassotalk.com
>>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>>> Send administrative queries to  <[hidden email]>
>>>>
>>>> #############################################################
>>>>
>>>> This message is sent to you because you are subscribed to
>>>> the mailing list Lasso [hidden email]
>>>> Official list archives available at http://www.lassotalk.com
>>>> To unsubscribe, E-mail to: <[hidden email]>
>>>> Send administrative queries to  <[hidden email]>
>>> #############################################################
>>>
>>> This message is sent to you because you are subscribed to
>>>    the mailing list Lasso [hidden email]
>>> Official list archives available at http://www.lassotalk.com
>>> To unsubscribe, E-mail to: <[hidden email]>
>>> Send administrative queries to  <[hidden email]>
>>
>> ɹǝıǝɯƃɹoq ɹoʌǝɹʇ
>>
>>
>> #############################################################
>>
>> This message is sent to you because you are subscribed to
>> the mailing list Lasso [hidden email]
>> Official list archives available at http://www.lassotalk.com
>> To unsubscribe, E-mail to: <[hidden email]>
>> Send administrative queries to  <[hidden email]>
>
> #############################################################
>
> This message is sent to you because you are subscribed to
>    the mailing list Lasso [hidden email]
> Official list archives available at http://www.lassotalk.com
> To unsubscribe, E-mail to: <[hidden email]>
> Send administrative queries to  <[hidden email]>


ɹǝıǝɯƃɹoq ɹoʌǝɹʇ


#############################################################

This message is sent to you because you are subscribed to
  the mailing list Lasso [hidden email]
Official list archives available at http://www.lassotalk.com
To unsubscribe, E-mail to: <[hidden email]>
Send administrative queries to  <[hidden email]>
12