The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Had a slight more indepth look, the API seems quite nice for doing simple operations, insert rows and what not.

Tried to add sqlite support [as I like sqlite for just hacking about in], using an assumption that the first column of the table is PK, and using 'SELECT * FROM `$table` WHERE 1 = 0', to get the column names and types.

But unfortunately if PDO returns no rows, you cant access the column metadata, which is pretty poor imo.

After the extreme hack of making sure the table(s) have atleast one row, using SELECT * FROM `table` LIMIT 1, did actually get the basic operations working.

I'm going to try to move to a more object-centric approach then the current sql-centric approach, how would you(and all others) that are familiar with orms feel about that? (not hiding sql in any way, just well... more of an "object"-feel and less of a "object-mixed-with-sql"-feel").

The current code (alpha 0.1) also holds some nasty bugs, etc - which I gotta sort out . Also trying to get a better "flow" of the codebase in the next release which will differ quite much from alpha 0.1 (inheritance should be in for once, more object-centric as I already mentioned).

The above also works with set/get:ers and protected properties but for simplicty I used public properties here

Then to save your object to the database - you have two choices:
1. Let Model try to auto-discover your datatypes (if you're lazy and only need float/integer/string)
2. Give model a "template" object which it will use to create the tables - such as:

So basicly, If you don't want to you have no need to create any SQL, Jointables, etc. at all - you create your objects, feed model a "template" object the first time you try to insert one object(these templates can be saved in %ModelAppDir%/templates/ and be autosensed, say Person.php for objects of type Person).

It will be able to map inheritance properly(I hope) and my "ObjectQuery"(which I've yet to get a better name) will be able to handle polymorphism.

I've also started playing with it - trying to get the tests to work into MSSQL

I've started hacking together a Metadata::loadMSSQLTableInfo() function. However, learning how to get MSSQL to tell me about the meta data is taking more reading of the online book than I expected! I've also got a set of unitTests/sql/mssql_XXX.txt files that seem to work ok.

Hmm.. from what you two are telling me you like the current approach I've got in Model Alpha 0.1 ? How would the people that tested the current Alpha 0.1 feel about moving into a more "object" approach in the one I described two posts above?

Also I think I'd like the idea of using some sort of Container. (see picoContainer, phemto) for registering DomainObjects, and handing that to the model for it to instance them. But I just maybe going overboard with Containers atm, as introduced them into my Routes solution, and doing stuff like

Hmm.. from what you two are telling me you like the current approach I've got in Model Alpha 0.1 ? How would the people that tested the current Alpha 0.1 feel about moving into a more "object" approach in the one I described two posts above?

I haven't played enough to have a preference. I quite like the idea about the templates though.

It would throw an Exception saying that age does not pass validation. It's also possible to build "custom" datatypes and use them instead, say you could build a custom datatype called Dollar, which would require a format such as '~^[\d\.]+\$$~' (expressed in regexp), extend it from the ModelStringField and changed the validate() method, voila. And it will ofc. be saved to the database (as string ofc, tho.)

From these maps I'm also able(or will be when the code works ;p) to generate database tables, link tables, and such.

Hmm.. not too sure about that. I say I'm not sure because incoming data is always a string datatype.

If the model knows that age should be an integer, then why not instead automatically cast it as an integer before validating?

I dunno, it just seems throwing an Exception like that because it is a string doesn't fit very well with PHP's type juggling. I think auto casting would better fit because then you could still keep strict guidelines for the properties, but not loose type juggling.

Hmm.. not too sure about that. I say I'm not sure because incoming data is always a string datatype.

You know what happends when you quote a string with PDO::quote() ? It get's " around it, I know MySQL can take strings as integers, but asfar as I can tell no other DB does that(and I for one think MySQL is wrong doing that).

Originally Posted by dreamscape

If the model knows that age should be an integer, then why not instead automatically cast it as an integer before validating?

Think lastcraft posted an idea of using a fluent style interface for defining table structures, which might be good.

Hmm.. interesting, where?

Edit: A thing I need advice on currently his how to do with the set/getMethods(), as currently the ModelClassReflector (wraps the ReflectionClass + ReflectionProperty + ReflectionMethod classes in a nicer interface just) looks for two methods that have the same name except the set/get prefix. Is this sufficent or should I look for a protected/private property named with the same name as the methods (w/o the prefix of set/get ofc.) ?

You know what happends when you quote a string with PDO::quote() ? It get's " around it, I know MySQL can take strings as integers, but asfar as I can tell no other DB does that(and I for one think MySQL is wrong doing that).

You've completely missed what I was saying.

Originally Posted by thr

Because if it is a string but should be a integer, it's invalid data.

That's ridiculous. All user data is a string. You're saying that all user data that you want to be something other than a string is inherently invalid. It is inherently untrustworthy, but that doesn't make it inherently invalid just because PHP reads it in as a string and not an integer. That's absurd, and pretty much flies right in the face of how PHP deals with types.

There's no logical reason that you shouldn't be able to do $person->age = '24'; and have it automatically mapped as an integer.

Let me put this another way... what exactly is the purpose of having datatypes in the model map templates, if you have to manually map the datatypes anyways?

Edit: A thing I need advice on currently his how to do with the set/getMethods(), as currently the ModelClassReflector (wraps the ReflectionClass + ReflectionProperty + ReflectionMethod classes in a nicer interface just) looks for two methods that have the same name except the set/get prefix. Is this sufficent or should I look for a protected/private property named with the same name as the methods (w/o the prefix of set/get ofc.) ?

Just the methods is probably good enough, another possibility with 5.1 is use Reflection*::getDocComment() and use a marker keyword in that.