On Aug 20, 2011, at 9:21 AM, Paul Hoadley wrote:
> Hi Kevin,
>
> On 19/08/2011, at 9:33 PM, Kevin Hinkson wrote:
>
>> The general consensus seems to be don't use primary keys in the way I
>> described, use another unique identifier/slug etc. But if one really, really
>> has to; then the follo
Hi Kevin,
On 19/08/2011, at 9:33 PM, Kevin Hinkson wrote:
> The general consensus seems to be don't use primary keys in the way I
> described, use another unique identifier/slug etc. But if one really, really
> has to; then the following are available:
Actually, my advice was subtly different.
anyone got a hint on a slice of code to do that short url magic?
if I were to start now, I guess I'd wait for the object to store in the DB, get
the primary key integer and modular arithmetically pick a character from a set
and add that to a character lineup which should reflect a unique choice
Yep, all depends on the number of potential collisions you care about. In
semi-controlled environments you can make do with fewer bits of uniqueness.
tb
On Aug 19, 2011, at 1:13 PM, Jesse Tayler wrote:
> how about those modern looking bit.ly type id's ?
>
> seems like you can take the key or
oh, ya, I hadn't seen that class but the idea is similar.
I guess because I was using the app not database, I put in an instance number
or something about the host/port or something.
this brings me to my next question --
how about those modern looking bit.ly type id's ?
seems like you can take
You're close to a real uuid at that point. The common problem is multiple
instance coordination, can be a lot easier just to have the DB assign a unique
value since you're probably coordinating there anyway. But it all depends on
your app, your db, your scaling characteristics, how many potentia
Hi Travis-
Is it impractical?
I've used a simple date+rand constructor and ran it through an encoding to HEX
to get a 'random' object id and had no troubles with that. I suppose it has
limits to uniqueness in theory but it was quick to generate.
I was also about to start looking for something
Unless you're generating a true guid that's impractical to do in a general way
at the app level.
tb
On Aug 19, 2011, at 8:03 AM, Kevin Hinkson wrote:
> This should be a common issue then. So I'm surprised there isn't some kind of
> slug generator that handles ensuring uniqueness in Wonder. (or
Hi Everyone,
Thanks for all of your suggestions.
The general consensus seems to be don't use primary keys in the way I
described, use another unique identifier/slug etc. But if one really, really
has to; then the following are available:
EOUtilities.faultWithPrimaryKey
EOUtilities.faultWithPrim
Just to clarify slightly, I happen to agree with Dave and Jesse, but that's
almost incidental to your original post. When I wrote this:
On 19/08/2011, at 9:37 AM, Paul Hoadley wrote:
> On 18/08/2011, at 11:05 PM, Kevin Hinkson wrote:
>
>> Since the best practice is to not make primary keys cla
Plus 1.
If your business logic does not require using keys as logic then you likely
want a generated unique id alongside your key.
There's a lot of reasons but some are that relational database keys have
complicated, even obtuse logic that can vary between database and even
versions.
As tim
Paul is right, as far as I'm concerned.
But, be really, really, really, really, really (really, really) sure you Need™
to expose it. Do everything you can to avoid it. If you only occasionally (in
code) need to get an object by it's PK, then use the
EOUtilities.faultWithPrimaryKey
EOUtilities
On 18/08/2011, at 11:05 PM, Kevin Hinkson wrote:
> Since the best practice is to not make primary keys class properties, how do
> I then create a qualifier that is based on the primary key of an EO?
My suggestion would be that you don't. Calling it a best practice isn't an
arbitrary designatio
EOUtilities.objectWithPrimaryKey
http://www.webobjects.me/API/wo542/com/webobjects/eoaccess/EOUtilities.html#objectWithPrimaryKey(com.webobjects.eocontrol.EOEditingContext,%20java.lang.String,%20com.webobjects.foundation.NSDictionary)
re: title. If you really want to trick out Google add an attr
On 18 Aug 2011, at 09:54, Pascal Robert wrote:
>
> Le 2011-08-18 à 09:47, Kevin Hinkson a écrit :
>
>>
>>>
>>> I'm not answering your question, but your URL should be /blog/title-of-post
>>> instead of using primary keys, to have even nicer URLs and better rank on
>>> Google. Are you using
Le 2011-08-18 à 09:47, Kevin Hinkson a écrit :
>
>>
>> I'm not answering your question, but your URL should be /blog/title-of-post
>> instead of using primary keys, to have even nicer URLs and better rank on
>> Google. Are you using DirectActions or ERRest's HTML routing?
>>
>
> Direct Acti
>
> I'm not answering your question, but your URL should be /blog/title-of-post
> instead of using primary keys, to have even nicer URLs and better rank on
> Google. Are you using DirectActions or ERRest's HTML routing?
>
Direct Actions. The example is just really an example though. There are
Le 2011-08-18 à 09:35, Kevin Hinkson a écrit :
> Hi,
> Since the best practice is to not make primary keys class properties, how do
> I then create a qualifier that is based on the primary key of an EO?
>
> Simple Eg: A blog site has nice, short bookmark-able URLs like
> http://website.com/blo
Use EOUtilities.faultWith. method.
Michael
Sent from my iPad
On Aug 18, 2011, at 9:35, Kevin Hinkson wrote:
> Hi,
> Since the best practice is to not make primary keys class properties, how do
> I then create a qualifier that is based on the primary key of an EO?
>
> Simple Eg: A blog s
Hi,
Since the best practice is to not make primary keys class properties, how do I
then create a qualifier that is based on the primary key of an EO?
Simple Eg: A blog site has nice, short bookmark-able URLs like
http://website.com/blog?id=5 where 5 is the primary key. When the user hits
that p
20 matches
Mail list logo
