UUIDs need way more "disk space". one might add that speed can also be
an issue.
having tables with a lot of foreign keys can be slowed down quite a
bit, even with indexing.
we have a project with uuids and tables with 1 records get really
really slow.
on the other hand UUIDs are very handy if
UUIDs are entirely unique while autoincrement ids are unique just for that
table. The benefit of UUIDs would be for things like merging tables,
merging other data, migrating the data elsewhere, etc. With UUIDs you
guarantee there won't be conflicts.
It's a matter of preference and depends on y
een INT and CHAR (uniqid) primary keys?
I know that uniqid keys would be more "safe" since you can't predict the
next or another valid ID but, besides that... there's any other diference?
Should I use it on every model or just the critical ones, like the Users
table?
--
Ou
ar 17, 2011, at 17:23, hill180 wrote:
>
>> From what I have read, I know that Cakephp does not support composite
>> primary keys. And later the posts go into tags, but I need a push in the
>> right directions.
>>
>> I have Tickets 1-100 that go out for each da
On Mar 17, 2011, at 17:23, hill180 wrote:
> From what I have read, I know that Cakephp does not support composite primary
> keys. And later the posts go into tags, but I need a push in the right
> directions.
>
> I have Tickets 1-100 that go out for each day.
>
> T
>From what I have read, I know that Cakephp does not support composite primary
>keys. And later the posts go into tags, but I need a push in the right
>directions.
I have Tickets 1-100 that go out for each day.
The user buys a ticket for a day and the system will process the pa
of it is because the
tables have no primary keys defined, and part because the foreign keys
are a little odd.
Currently, my models are as follows:
PHP Code
array ( foreignKey => false,
conditions => array
(’ScheduledDate.mode
Hi,
Does anyone know if cake core has any problems saving HABTM tables
using text keys instead of numeric?
I have and edit method in a controller that is supposed to save data
to it's main table and 3 HABTM.
Two of them work just as expected, first removing all of the rows in
the table and then
I work in a company with a legacy database designed using relations
with composite primary keys and change the database is not an
option...
Cake does not support an array of keys by default to set model`s
$primaryKey.
Is there any plugin or update in sight
On Sep 2, 7:58 am, jpt2 <[EMAIL PROTECTED]> wrote:
>
> The 'indexes' part looked a bit suspicious but I ran the test anyway
> athttp://forcetrak.dev/app/webroot/test.php?case=models%5Crank.test.php...
> and got this:
>
Note that the URL I mention here is local only, and not internet
accessible..
Currently using cake_1.2.0.7296-rc2 and postgres 8.2.5
I have a table that looks like this:
CREATE TABLE ranks
(
id serial NOT NULL,
code character varying(1) NOT NULL,
description character varying(15) NOT NULL,
CONSTRAINT ranks_pkey PRIMARY KEY (id)
)
WITH (OIDS=FALSE);
ALTER TABLE ran
nvm. i got it thx
On Fri, Apr 18, 2008 at 2:16 AM, . <[EMAIL PROTECTED]> wrote:
> for habtm tables in general, how would you handle updates? or deletes?
>
>
> On Thu, Apr 17, 2008 at 7:47 AM, Baz <[EMAIL PROTECTED]> wrote:
>
> >
> > But wait...
> >
> > isn't food_categories with only 2 columns a
for habtm tables in general, how would you handle updates? or deletes?
On Thu, Apr 17, 2008 at 7:47 AM, Baz <[EMAIL PROTECTED]> wrote:
>
> But wait...
>
> isn't food_categories with only 2 columns a HABTM table?
>
> Am I missing something here?
>
> >
>
--~--~-~--~~~--
But wait...
isn't food_categories with only 2 columns a HABTM table?
Am I missing something here?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to cake-php@goog
CakePHP does not support composite primary keys. This has been
discussed at length. Just add an auto-incrementing column to your
table and make that the primary key [ change your primary key index to
a unique index first ].
> How do I delete a row? I cannot seem to do $this->FoodCategor
do $this->FoodCategory->del($id)
>
> On Wed, Apr 16, 2008 at 2:33 PM, Baz <[EMAIL PROTECTED]> wrote:
> > I don't follow.
>
> > This table (if we're talking about Cake standards and conventions) is a
> > HABTM table. You don't update this manual
llow.
>
> This table (if we're talking about Cake standards and conventions) is a
> HABTM table. You don't update this manually. Also, these tables don't have
> primary keys.
>
> You would rather change the associated Models. So do a read on your Food
> table
I don't follow.
This table (if we're talking about Cake standards and conventions) is a
HABTM table. You don't update this manually. Also, these tables don't have
primary keys.
You would rather change the associated Models. So do a read on your Food
table for food_
I have a table foods_categories with columns: food_id and category_id (the
primary keys are food_id and category_id)
Let's say I insert the values (1,2) into this table. Let's say I want to
update the row to (1,3). How would I update this row?
Normally, if I implement the table with t
Hi is this the correct way to relate data like this? I switched them
around and it still doesn't work the way I need it to.
On Mar 7, 8:19 pm, Walker Hamilton <[EMAIL PROTECTED]> wrote:
> you need to read this:
>
> http://book.cakephp.org(especially the models part).
>
> Your belongsTo and hasOne
you need to read this:
http://book.cakephp.org (especially the models part).
Your belongsTo and hasOne forum keys are wrong.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, s
I have a Thread modeal with associated models ForumUser and
ForumCategory:
var $hasOne = array('ForumUser' =>
array('className' => 'ForumUser',
'conditions' => '',
'order' => '',
It seems like the idea of having more meaningful primary keys doesn't
have any obstacles. I'll continue with that.
Thanks everyone!
On Feb 15, 9:12 pm, nate <[EMAIL PROTECTED]> wrote:
> You can use any kind ofprimarykey you want, so long as it doesn't
> include more
ained on a trigger.
>
> That's an idea that I hadn't considered.
>
> However, I'd only consider this route if someone confirms that my user-
> friendly primary keys are not recommended in Cake for some reason.
--~--~-~--~~~---~--~~
You
gger.
>
> That's an idea that I hadn't considered.
>
> However, I'd only consider this route if someone confirms that my user-
> friendly primary keys are not recommended in Cake for some reason.
--~--~-~--~~~---~--~~
You received this message b
> You could set up a "shadow" field in the table to store the human
> readable form of theprimarykey, maintained on a trigger.
That's an idea that I hadn't considered.
However, I'd only consider this route if someone confirms that my user-
friendly primary keys
You could set up a "shadow" field in the table to store the human
readable form of the primary key, maintained on a trigger. Your users
get their pretty field values and don't need to join and cakePHP still
happily works with its expected "id" integer field..?
Dunc.
--~--~-~--~~-
unenlightened. Hence my desire for primary keys
> which are meaningful.
>
> From your answer it seems that Cake would have no problem with my
> idea. One of my doubts was whether anyone would propose the
> following:
>
>
ly straightforward to anyone knowing SQL, it can be quite tricky
> for those who are unenlightened. Hence my desire for primary keys
> which are meaningful.
>
> From your answer it seems that Cake would have no problem with my
> idea. One of my doubts was whether anyone would propose the
unenlightened. Hence my desire for primary keys
which are meaningful.
>From your answer it seems that Cake would have no problem with my
idea. One of my doubts was whether anyone would propose the
following:
Contacts
idLastnameContacttype_
't.
But regardless of what your app. can and cannot do, this is not a CakePHP
specific problem. As far as I am aware, your primary keys can be anything of
your choosing. Obvious, if it's not auto-incrementing then you are
personally going to have to manage how they get set when you add
Cont
I notice that everyone using Cake seems to use autoincrementing
integer primary keys. However this means you always have to join the
code files for all queries and reports because the keys don't mean
anything (unless you can memorize lots of numbers).
In the past I have successfully used
On 11/9/07, Mr-Yellow <[EMAIL PROTECTED]> wrote:
> Nice to know I just spent months designing a massive properly
> normalised and indexed database.
> Only to findout Cake doesn't support properly designed databases.
After designing the theoretical correct model, I always thought there
was an addi
Ben
From an academic standpoint [and yes best practice DB design] the us of
composite FKs to create a PK is common.
Many of my designs in the past used that idea, but with the introduction of so
many QaD [Quick and Dirty] methods [aka Rapid Application Development]
sometimes the best practic
Oh just to let you know. Yes I do know what a Unique Index is.
We don't really need fanboys to come yell at us that it's 2007.
The year doesn't change the fact that doing stuff on the DB engine is
safer then in your software.
Validation is still very important, but a properly setup database is
be
YaY!!!
Nice to know I just spent months designing a massive properly
normalised and indexed database.
Only to findout Cake doesn't support properly designed databases.
Lock this thread too, just to make sure discussion of their benefit is
quashed and discovery of the feature hole is less obvious
y changing any of the cake core code, but
maybe inheriting something and overloading. But that seems pretty tough going.
Also I feel my passing of array() keys had to be changed to something
more intuitive (then again, cake makes extensive use of arrays).
Might be we could abstract (primary) keys
The patches seem like they would work just fine, but that's just me
looking at them, not having tested them. I'll take it on faith that
they're well tested. However, if you search the Cake core for
'primaryKey,' you'll find that it is used in many other places, and IMO
changing them all would be
> In developing Cake, we've chosen to adhere to certain conventions in
> order to keep things simple. That's what makes Cake work. The
> decision not to allow the use of mutli-column primary keys is
> reflective of the opinions inherent to the framework.
Aha, that sound
complex SQL.
In developing Cake, we've chosen to adhere to certain conventions in
order to keep things simple. That's what makes Cake work. The
decision not to allow the use of mutli-column primary keys is
reflective of the opinions inherent to the framework.
The rest of Josh's bulle
> Here's a bit of discussion that took place here a few weeks ago...
>http://groups.google.com/group/cake-php/browse_thread/thread/d2bf4bb245201cb/015f0feefd9ff482?lnk=gst&q=composite&rnum=1#015f0feefd9ff482
Thats not really a discussion.
"And Tony Marston is the last person I would be reading f
(first off: this isn't meant as criticism or a way for me to point out
there are shortcomings in the cakephp (RoR/ORM/... ) way, it's more of
a 'live, discuss & learn' conversation for me)
> Well, the first one was quite interesting in the way it condemned the
>
Well, the first one was quite interesting in the way it condemned the
use of primary keys altogether. I think it's way off base, but still
interesting.
The bottom line for me is that (a) it introduces needless complexity
into the system, and (b) not only does the practice of using join
nate wrote:
> You're not out of luck, you just need to add a primary key. The reason
> for this is that composite primary keys are a monumentally *bad* idea.
Why exactly are they a bad idea ?
They're used in many (serious) rdbms designs and are automatically constrained
(which
Here's a bit of discussion that took place here a few weeks ago...
http://groups.google.com/group/cake-php/browse_thread/thread/d2bf4bb245201cb/015f0feefd9ff482?lnk=gst&q=composite&rnum=1#015f0feefd9ff482
--~--~-~--~~~---~--~~
You received this message because you
You're not out of luck, you just need to add a primary key. The reason
for this is that composite primary keys are a monumentally *bad* idea.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "Cake
PHP&
It seems this one pops up almost as frequently as HABTM questions.
If you've got a rdbms design where a join table looks likes this:
CREATE TABLE authors_posts (
author_id INTEGER REFERENCES authors(id) ON DELETE CASCADE,
post_id INTEGER REFERENCES posts(id) ON DELETE CASCADE,
type
47 matches
Mail list logo
