mrtomash / vanilla-mvc Goto Github PK

Steps to reproduce:

$q = 'INSERT INTO mytable (column, column2) VALUES (?:mycolumn, ?:mycolumn2)';
$dbh->do_($q, array(), array('mycolumn' => 'foo', 'mycolumn2' => 'bar'));

Expected executed query:

INSERT INTO mytable (column, column2) VALUES ('foo', 'bar');

Actual Result:

INSERT INTO mytable (column, column2) VALUES ('foo', 'bar'2)

I was trying to setup vanilla in a sandbox on my machine and ran into some
problems with the configure script. Running "sh ./vanilla/configure.sh" by
itself returns an error when running shift because no argument was
supplied. Reading your tutorials it shows that there used to be, I'm
guessing, a check in the configure script that would see if you are missing
the installation path. If it were missing it would show a usage description.

Setting all that aside, enclosed is a diff for the (simple) fix.

Thanks.

This isn't a defect but a feature for SchemaTable.php. This adds a new sql
condition: notequal.

Diff file is attached.

$ svn checkout http://vanilla-mvc.googlecode.com/svn/trunk/ vanilla-mvc
$ sh vanilla-mvc/configure.sh
$ vanilla-mvc/configure.sh: the directory you run this script from must
contain the vanilla directory

Either line 22 in configure.sh needs to have the "/vanilla"-specific
references removed, or add in "/vanilla-mvc" to the mix, as that's the
specified folder to checkout the source to in the Source tab of Google Code.

For people to start using vanilla-mvc on multi-tiered architecture, we
absolutely need libmemcached support. For the API, we should be able to:

1) Attach pools of memcached servers to groups. If we want to store a
certain object on a server pool that only handles sessions, we'd identify
it with a "session" group name. Or if we have a pool that handles just a
messaging portion of our site, we'd call it "messages". And if a developer
doesn't want to split them off into pools, then we have a "global" group
that will be accessed if no groupName is given in ->memcached() [see item
2]. Obviously the group names are developer-defined in a config file
somewhere. 

Example pool array would be:
 $memcached_pool = array(
   "global" => array(
     // list of global servers
   ),

   "messages" => array(
     // list of message servers
   )
 );

2) Ability to cache anything, whether it be manual queries or objects. To
completely do this, we will have to tap into ::find() and ::find_first().
I'm not completely sure how we want to do that just yet. For caching manual
queries, we can call the ->memcached() method in the DBIdbh class before we
run ->execute();  ->memcached() can have 3 arguments:

 * groupName: For segmenting this memcached store call out to a specific
server pool. Default: "global"
 * cacheDirective: This would instruct memcached what to do. 0 would not
cache, and pull directly from the database. 1 will cache if not already
cached, and pull from cache. 2 will pull from the database and recache the
object regardless of the set TTL. Default: 0
 * cacheTTL: This sets the TimeToLive for the stored object. Default: 0

need a DBDmysqli object that uses mysqli family of functions for
compatiblity with more environments

save_insert attempts to insert a row with a value for all columns for the
row defined, even if the value is null. The following patch will only
insert values as called from save(), resulting in correct behavior for rows
specified NOT NULL. 

additionally, some debugging statements were left uncommented. these have
been commented accordingly.

Model.php.patch is a patch against r304

render_attributes() isn't called at all during the process of building a
hidden element. makes building "ajaxy" applications a real pain in the ass.

saving existing rows using model::find and $model->save() does not result
in the changes being saved as expected.

line 864 in dbmodels/3/Model.php reads:

if ($this->changed($col)) continue;

which results in changed columns being skipped in the update query. the net
result is all of the non-updated columns are saved.

changing that line to

if (!$this->changed($col)) continue;

results in expected behavior.

What steps will reproduce the problem?
1.  Create a table w/o primary key
2.  use table::find()


What is the expected output? What do you see instead?
You should see each row in the table, instead you see the first row the 
correct number of rows times


What version of the product are you using? On what operating system?
Original, Linux

Please provide any additional information below.

accept a list of values on which to bind output results (i.e.
mysqli_stmt::bind_result).

The arrays returned by table_info and column_info are dbdriver dependent. 
The should be the same format as much as necessary to increase database
independence.

A nice feature for limited database, shared hosting environments would be
to support prefixes on the table names without having to name the models
(and the foreign keys) to have the prefixes also.

Manually querying a query that vanilla was running would return 2 different
rows. In vanilla, however, it was returning the first row twice. 

I thought it was a caching issue, turned off caching and it was fine.
Turned it back on, attempted to clear the cache with the forget() commands
and that didn't work.

So I changed the id of the row in MySQL, reran the controller and it would
pull back exactly the same thing (only this time with the different id).

Turns out my table had 3 primary keys set. Support for multi-keyed tables
is a must.

support all PDO drivers in dbi, pretty much just aliasing the functionality
to the dbi API.

it would also be good to support PDO's prepared statements rather than
using the prepared statement emulation, however the syntax is not exactly
compatible.

Ability to do an OR query with find() and find_first(), possibly by doing a
sub-array within the condition array.

Example: table_name::find(array('cond1' => true, array('cond2' => 1,
'cond3' => 2)));

Would produce: SELECT * FROM table_name WHERE cond1 = true AND (cond2 = 1
OR cond3 = 2);

http://www.phpdoc.org

This should help us to easily build project documentation that will always
be up to date.

The urldecode on line 35 should be removed.

Because the classes in the Model inheritance chain (mainly for
vanilla/dbmodels/3) are used statically and define a lot of static class
members, the ORM can only be used with one database/database connection.

Not sure if this is worth doing anything about, or how it might be fixed
and still retain the static invocation of model methods.

See comments on r290.

When looking to find bottlenecks I became tired manually running queries to
see how long they were taking. The attached diff adds in the execution time
to the debug log message for each query.