Re: Single thread creation queue?
Re: Single thread creation queue?
- Subject: Re: Single thread creation queue?
- From: Jesse Tayler via Webobjects-dev <email@hidden>
- Date: Mon, 22 Nov 2021 12:23:01 -0500
Oh? Thanks - I hadn’t heard of such a thing. This would be Amazon RDS which is
basically MySQL and likely has similar.
Either way I guess I should delete any dups, they either cause an error
somewhere or at least integrity problems I don’t need.
Is there a good wiki page on migration examples out there?
> On Nov 22, 2021, at 11:19 AM, Aaron Rosenzweig <email@hidden> wrote:
>
> Sounds like you are using Postgres?
>
> You can use the syntax “not valid” when you create a constraint to stop the
> bleeding immediately. It will then only check for new and modified records
> allowing the bad rows to co-exist. When you get around to it, you can remove
> the duplicates.
>
> If it’s another database, they likely have something similar.
>
>> On Nov 22, 2021, at 10:18 AM, Jesse Tayler <email@hidden> wrote:
>>
>> It’s not a compound key so much as just policy — it’s a handle for social
>> service and so there should just be one row with that value and don’t need
>> to tie into the key
>>
>> I guess I can create a unique index just for that one attribute and it would
>> presumedly return an error upon save. I should re-write the EO to handle
>> that error raise and respond by returning the existing object…
>>
>> I guess that is not hard to figure if that approach sounds sane.
>>
>> I do have dups and I’d guess the constraint will simply fail if the database
>> has any dups in it.
>>
>> I guess writing a migration to handle / remove dups is not practical so I’d
>> likely remove them by hand, then add the constraint in a migration update
>> that would gently fail until there are no more dups…
>>
>>
>>
>>> On Nov 22, 2021, at 10:07 AM, Samuel Pelletier <email@hidden> wrote:
>>>
>>> Jesse,
>>>
>>> So your row have a primary key and some other unique identifier derived
>>> other attributes.
>>>
>>> If the compound key is a combinaison of full attribute values, you cana a
>>> compound unique key in the database. CREATE UNIQUE INDEX ON Table (col1,
>>> col2, ..., coln)
>>>
>>> If it is from partial values, the most reliable way is to add a string
>>> column with the computed key with it's unique constraint.
>>>
>>> If you already have duplicate, you can add a method in the migration to
>>> resolve them before adding the constraint or do it manually...
>>>
>>> Regards,
>>>
>>> Samuel
>>>
>>>> Le 22 nov. 2021 à 09:27, Jesse Tayler <email@hidden> a écrit :
>>>>
>>>> It’s likely just a unique constraint perhaps.
>>>>
>>>> It’s not UIDs or primary keys it’s a unique row type based on a couple
>>>> strings where there should be only one, and that one should last forever.
>>>>
>>>> There’s an API where calls can come in basically at the same time and
>>>> instead of fetching first to see if the object exists, I should likely
>>>> respond to an SQL error rejecting a new row and then fetch and return that
>>>> existing object based on that error condition.
>>>>
>>>> I’d suppose the database is the best place for that policy, but I don’t
>>>> think I’ve implemented constraints quite like that before so I’d need to
>>>> write some sort of Migrations for it if it’s to be reliable in all those
>>>> situations where it might encounter duplicate data…hmmm…
>>>>
>>>>
>>>>
>>>>
>>>>> On Nov 22, 2021, at 8:59 AM, Samuel Pelletier <email@hidden> wrote:
>>>>>
>>>>> Hi Jesse,
>>>>>
>>>>> Your question may have multiple answers, can you describe the contexts
>>>>> and duplicate sources you fear ?
>>>>>
>>>>> Is the primary key generated by the WO app or it is external (like a
>>>>> GUID) ?
>>>>>
>>>>> Do you have a secondary identifier that should be unique ?
>>>>>
>>>>> Anyway, you should add constraint in to the database if uniqueness is
>>>>> required (this apply to all frameworks in all language)
>>>>>
>>>>> If you use EOF primary key generation, you should not have problems with
>>>>> duplicate keys. If you require high throughput, using UUID primary key or
>>>>> implementing a custom generator will help by saving round trips to the
>>>>> database server. If you insert in batch, it will be also faster than
>>>>> individual inserts.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Samuel
>>>>>
>>>>>> Le 22 nov. 2021 à 08:34, Jesse Tayler via Webobjects-dev
>>>>>> <email@hidden> a écrit :
>>>>>>
>>>>>> I asked on slack but I figured I’d ping the list
>>>>>>
>>>>>> Who has a good way to ensure a serial EO creation queue when the system
>>>>>> could be hit really fast and you must avoid duplicate entries?
>>>>>>
>>>>>> I’m a bit surprised I don’t recall EOF style solutions for such things
>>>>>> and maybe the Amazon RDS database has a shared connection pattern the
>>>>>> apps can use, I didn’t see anything so I figure this is application
>>>>>> level stuff.
>>>>>>
>>>>>> Thoughts? Suggestions?
>>>>>> _______________________________________________
>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>> Webobjects-dev mailing list (email@hidden)
>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>
>>>>>> This email sent to email@hidden
>>>>>
>>>>
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden