Nabble - SolarPHP Talk

Extending Solar config

2009-12-12T14:13:48Z

I have looked at postConfig/preConfig and load_callback and they only half solve my current problem/train of thought.

Basically I would like to load config items from a DB, which by itself is easy and can be done with the above methods.. My problems/thoughts on this are as follows

1. You have to load everything up front.. No way to load on access (IE if we don't use App_Class_Something this page load why spend the time/money loading the config)
2. Some of the things I am playing with are command line daemons and some things can be changed on the fly but the config is read only.

What I envision is the ability to load config on demand.. And being able to "clear" whats in memory when needed to either force a reload of the classes config or to save memory.

The third thought is I am going down the wrong path all together to begin with and thats not what Solar_Config is for... My thought on this is to have all config within the same system...

I do think that item 1. is a important point to consider regardless because as the apps built with Solar get bigger and bigger, the overhead of "load it all" can become an issue.

Richard Thomas
http://www.cyberlot.net

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

sfer Solar Framework Extension Repository

2009-12-02T18:14:18Z

Needed a place to work/put some Solar stuff I was working on.

http://code.google.com/p/sfer/

First being a controller used to integrate jquery and Solar

http://code.google.com/p/sfer/source/browse/trunk/Sfer/Controller/Jquery.php

and the example app that goes along with it

http://code.google.com/p/sfer/source/browse/#svn/trunk/Sfer/App

Allows you to call class methods using jquery and also inject jquery methods into a page.

Richard Thomas
http://www.cyberlot.net

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: help with hasMany belongsTo

2009-11-27T09:33:54Z

> 'eager' => array(
> 'cricket_team_players',
> 'cricket_scores' => array(
> eager => array(
> 'cricket_score_innings',
> 'cricket_score_bowling',
> )
> )
> )
> modifying your first query to the above should work, no?

Quick try, seems to do the trick, thank you kind sir!

Now all I need to do is get a single form that will add/update all those
related tables, to work without borking everything :D

Thanks again

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: help with hasMany belongsTo

2009-11-27T08:24:21Z

'eager' => array(
'cricket_team_players',
'cricket_scores' => array(
                 eager => array(
                            'cricket_score_innings',
'cricket_score_bowling',
                  )
         )
)

modifying your first query to the above should work, no?

Anthony Gentile

On Fri, Nov 27, 2009 at 9:04 AM, Jeff Surgeson <jeff@...> wrote:

Hi All

Trying to do a data model for a cricket club and need some advice from the
Solar_Sql_Model "Fundi's"

Apologies in advance for the drawn out explanation, but complex relationships
scramble my brains, so I need to lay it out so I dont confuse myself, not
that it takes much :D

Below is my data models and relationships, all seems to work ok except some
part of the relationships is missing, or wrong, as I dont get back all that I
would like.

If I run a query on CricketTeams

'eager' => array(
'cricket_team_players',
'cricket_scores',
)

I get cricket_teams with related
cricket_team_players_collection
cricket_scores_collection

If I run a query on CricketScores

'eager' => array(
'cricket_teams',
'cricket_score_innings',
'cricket_score_bowling',
)

I get back cricket_scores with related
cricket_teams_record
cricket_scores_innings_collection
cricket_scores_bowling_collection

How do I set up the relationship so that if I run a query on cricket_teams it
also returns the innings and bowling collections as it does when I run the
query on cricket_scores, and not just the cricket_scores_collection?

#######################
Standardcricket_Model_CricketTeams

cols = team_id

$this->_hasMany cricket_team_players
'foreign_class' => 'Standardcricket_Model_CricketTeamPlayers',
'foreign_key' => 'team_id',

$this->_hasMany cricket_scores
'foreign_class' => 'Standardcricket_Model_CricketScores',
'foreign_key' => 'team_id',

Standardcricket_Model_CricketTeamPlayers

cols = player_id team_id

$this->_belongsTo cricket_teams
'foreign_class' => 'Standardcricket_Model_CricketTeams',
'foreign_key' => 'team_id',

#######################
Standardcricket_Model_CricketScores

cols = scores_id team_id innings_id bowling_id

$this->_belongsTo cricket_teams
'foreign_class' => 'Standardcricket_Model_CricketTeams',
'foreign_key' => 'team_id',

$this->_hasMany cricket_score_innings
'foreign_class' => 'Standardcricket_Model_CricketScoreInnings',
'foreign_key' => 'scores_id',

$this->_hasMany cricket_score_bowling
'foreign_class' => 'Standardcricket_Model_CricketScoreBowling',
'foreign_key' => 'scores_id',

##########################
Standardcricket_Model_CricketScoreInnings

cols = innings_id scores_id

$this->_belongsTo cricket_scores
'foreign_class' => 'Standardcricket_Model_CricketScores',
'foreign_key' => 'scores_id',

###########################
Standardcricket_Model_CricketScoreBowling

cols = bowling_id scores_id

$this->_belongsTo cricket_scores
'foreign_class' => 'Standardcricket_Model_CricketScores',
'foreign_key' => 'scores_id',

Regards
Jeff Surgeson

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

help with hasMany belongsTo

2009-11-27T07:02:41Z

Hi All

Trying to do a data model for a cricket club and need some advice from the
Solar_Sql_Model "Fundi's"

Apologies in advance for the drawn out explanation, but complex relationships
scramble my brains, so I need to lay it out so I dont confuse myself, not
that it takes much :D

Below is my data models and relationships, all seems to work ok except some
part of the relationships is missing, or wrong, as I dont get back all that I
would like.

If I run a query on CricketTeams

'eager' => array(
'cricket_team_players',
'cricket_scores',
)

I get cricket_teams with related
cricket_team_players_collection
cricket_scores_collection

If I run a query on CricketScores

'eager' => array(
'cricket_teams',
'cricket_score_innings',
'cricket_score_bowling',
)

I get back cricket_scores with related
cricket_teams_record
cricket_scores_innings_collection
cricket_scores_bowling_collection

How do I set up the relationship so that if I run a query on cricket_teams it
also returns the innings and bowling collections as it does when I run the
query on cricket_scores, and not just the cricket_scores_collection?

#######################
Standardcricket_Model_CricketTeams

cols = team_id

$this->_hasMany cricket_team_players
'foreign_class' => 'Standardcricket_Model_CricketTeamPlayers',
'foreign_key' => 'team_id',

$this->_hasMany cricket_scores
'foreign_class' => 'Standardcricket_Model_CricketScores',
'foreign_key' => 'team_id',

Standardcricket_Model_CricketTeamPlayers

cols = player_id team_id

$this->_belongsTo cricket_teams
'foreign_class' => 'Standardcricket_Model_CricketTeams',
'foreign_key' => 'team_id',

#######################
Standardcricket_Model_CricketScores

cols = scores_id team_id innings_id bowling_id

$this->_belongsTo cricket_teams
'foreign_class' => 'Standardcricket_Model_CricketTeams',
'foreign_key' => 'team_id',

$this->_hasMany cricket_score_innings
'foreign_class' => 'Standardcricket_Model_CricketScoreInnings',
'foreign_key' => 'scores_id',

$this->_hasMany cricket_score_bowling
'foreign_class' => 'Standardcricket_Model_CricketScoreBowling',
'foreign_key' => 'scores_id',

##########################
Standardcricket_Model_CricketScoreInnings

cols = innings_id scores_id

$this->_belongsTo cricket_scores
'foreign_class' => 'Standardcricket_Model_CricketScores',
'foreign_key' => 'scores_id',

###########################
Standardcricket_Model_CricketScoreBowling

cols = bowling_id scores_id

$this->_belongsTo cricket_scores
'foreign_class' => 'Standardcricket_Model_CricketScores',
'foreign_key' => 'scores_id',

Regards
Jeff Surgeson

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T22:57:38Z

> Thanks for this, Jeff. I am sure I will have to do something similar
> soon, so I will save this as an example of 'howto'.

Well that will make a nice change from me always asking :)

> Cricket. Now there's a game I have never had time to figure out :)

Me neither, find it kinda pointless, had no choice as I am doing a site for a
cricket club, you dont have a spare data model for a
team/player/profile/scorecard/stats, do you? :D

Take care
jeff
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T18:04:46Z

Thanks for this, Jeff. I am sure I will have to do something similar
soon, so I will save this as an example of 'howto'.

Cricket. Now there's a game I have never had time to figure out :)

On Tue, 2009-11-24 at 01:22 +0200, Jeff Surgeson wrote:

> Thanks to all for the pointers and help, I am able to use my solar app without
> modification, my script executes it periodicaly and saves to cache, my web
> scripts then only load from cache, works like a charm. :D
>
> I did the following::
>
> 1. set up crontab to run periodically
> 2. created a solar bootstrap file php script for the cron job to run
> 3. created minimal config file
>
> // my bootstrap php script file
> $system = dirname(dirname(__FILE__));
> set_include_path("$system/include");
> require_once 'Solar.php';
> $config = "$system/config/Cron.config.php";
> Solar::start($config);
>
> $feeds = array(
> 'rss-cricket' => 'http://www.supersport.com/rss/default.aspx?site=3',
> 'rss-cycling' => 'http://www.supersport.com/rss/default.aspx?site=7',
> 'rss-motorsport' => 'http://www.supersport.com/rss/default.aspx?site=6',
> );
>
> foreach ($feeds as $area => $url) {
> $rss = Solar::factory('Badger_Rss', $config = array(
> 'cache_active' => true,
> 'cache_adapter' => 'Solar_Cache_Adapter_File',
> 'cache_life' => 3600,
> 'cache_prefix' => 'RssCron',
> 'content_area' => $area,
> ));
> $rss->load($url);
> }
> Solar::stop();
>
> // my config file
> $config = array();
> $system = dirname(dirname(__FILE__));
> $config['Solar']['system'] = $system;
> return $config;
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Relationship Advice

2009-11-23T18:02:51Z

Couldn't resist that subject line :)

Actually, this isn't about advice, but rather clarification that I
understand some of the relationship naming reasoning.

The majority of relationships I work with are hasMany/belongsTo. Today I
was setting up a hasOne/belongsTo but ran into a snag.

Normally, I set them up like this:

$this->_hasMany('my_table', array('foreign_key'=>'some_id'));

Where 'my_table' is the name of the table. This generally works as
expected.

Today I tried this:

$this->_hasOne('my_table', array('foreign_key'=>'some_id'));
But this didn't work. Solar tried to find Vendor_Model_MyTables

The _setForeignClass() method assumes the relationship name is singular
and should, therefore, look for a pluralized model.

With the hasMany, _setForeignClass() assumes the relationship name is
already plural and doesn't pluralize it.

This confused me a little since I was, by default, using the table name
as the relationship name. Normally, this works well, since my tables are
typically pluralized (invoices, users, categories, etc).

So, just to confirm, the idea for naming relationships is as follows:

$this->_hasMany('foos');
Looks for Vendor_Model_Foos

$this->_hasOne('foo');
Looks for Vendor_Model_Foos

Yes?

And if need be this can be overridden with 'foreign_class' option.

Therefore, as a naming convention, use plurals for the models.
This makes sense to me from an English language perspective, but threw
me off for a minute.

I am mostly just writing this to get it straight in my head. If anything
seems wrong, let me know.

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: Reviewing the Unfounded branch

2009-11-23T16:02:48Z

On Oct 14, 2009, at 6:14 PM, Paul M Jones wrote:

> To repeat from earlier in this thread, the intended benefit of "empty
> record/collection" was to remove the need for the following idiom in
> records where you need to access a related object:
>
> // where 'foo' is a related record or collection ...
> if (! $this->foo) {
> $this->foo = $this->newRelated('foo');
> }

Just for emphasis, this could be rewritten as

// If foos is not a collection, convert it to a collection so we can call methods on it
if (!($record->foos instanceof Solar_Sql_Model_Collection)) {
$record->foos = $record->getModel()->newRelated('foos', $record->foos);
}

By all means, get rid of the need to do that.

However

// If there is no foo record, create one
if (!$record->foo) {
$record->foo = $record->getModel()->newRelated('foo');
}
$record->save();

Is fine in my book.

Also, note that this only makes sense for hasOne relationships. Because of the way that save cascades if you try to use this notation with a BelongsTo relationship, the record created doesn't save.

I just don't see this idiom as onerous for hasOne relationships and records and you'd never use it for BelongsTo.

Jeff
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T15:21:06Z

Thanks to all for the pointers and help, I am able to use my solar app without
modification, my script executes it periodicaly and saves to cache, my web
scripts then only load from cache, works like a charm. :D

I did the following::

1. set up crontab to run periodically
2. created a solar bootstrap file php script for the cron job to run
3. created minimal config file

// my bootstrap php script file
$system = dirname(dirname(__FILE__));
set_include_path("$system/include");
require_once 'Solar.php';
$config = "$system/config/Cron.config.php";
Solar::start($config);

$feeds = array(
'rss-cricket' => 'http://www.supersport.com/rss/default.aspx?site=3',
'rss-cycling' => 'http://www.supersport.com/rss/default.aspx?site=7',
'rss-motorsport' => 'http://www.supersport.com/rss/default.aspx?site=6',
);

foreach ($feeds as $area => $url) {
$rss = Solar::factory('Badger_Rss', $config = array(
'cache_active' => true,
'cache_adapter' => 'Solar_Cache_Adapter_File',
'cache_life' => 3600,
'cache_prefix' => 'RssCron',
'content_area' => $area,
));
$rss->load($url);
}
Solar::stop();

// my config file
$config = array();
$system = dirname(dirname(__FILE__));
$config['Solar']['system'] = $system;
return $config;
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: Reviewing the Unfounded branch

2009-11-23T15:19:03Z

Picking up from a conversation of old...

On Oct 14, 2009, at 6:14 PM, Paul M Jones wrote:

> To repeat from earlier in this thread, the intended benefit of "empty
> record/collection" was to remove the need for the following idiom in
> records where you need to access a related object:
>
> // where 'foo' is a related record or collection ...
> if (! $this->foo) {
> $this->foo = $this->newRelated('foo');
> }
> // ... now you can be sure that $this->foo is actually there
>
> Every time you need the related 'foo', you need to check if it's
> really there or not. This is true for both records and collections.
>
> That is the idiom I very much want to get rid of. It's really under
> my skin.

I agree, having to convert representations is low value code.

> It struck me recently that the use case I'm talking about happens
> always and only within record objects.
>
> What say if the "empty" objects are used *only* within a record; i.e.,
> with related records and collections on a record object? The idea
> would be that a normal fetch*() call returns null or array as before ...
>
> $item = $model->foos->fetchOne(); // null
> $list = $model->foos->fetchAll(); // array()
>
> ... but *related* elements on a record get the "empty object" treatment:
>
> $item = $model->foos->fetchOne(); // a found record
> $item->bars; // an empty collection object
> $item->baz; // an empty record object

I'm ok with doing this for collections, but not for records.

if (! $this->foos) {
$this->foos = $this->newRelated('foos');
}

for a collection this is just a simple conversion between empty array and empty collection. You could freely convert back and forth between the two. The only reason to prefer the collection is to be able to make method calls on the collection. Note, this works in trunk today.

I could just as easily do this:

if (count($this->foos) == 0) {
$this->foos = array();
}

To go in the opposite direction.

Now lets say that I execute this code in trunk today on a toMany relationship:

if (! $this->foos) {
$this->foos = $this->newRelated('foos');
}

Any down stream code MUST be prepared to deal with the fact that there is an empty collection representing the relationship. any code that does not prepare for the possibility that $record->foo can be an empty collection instead of an empty array is probably buggy.

Thus, changing from array() to empty collection as the default representation for empty for toMany relationships is a relatively minor change. Any bugs are not new bugs introduced, they are existing bugs revealed.

This is NOT the case on the record side. There is no concept of an empty record in trunk. That is completely new. for a toOne relationship this code is not a simple representational conversion:

if (! $this->foo) {
$this->foo = $this->newRelated('foo');
}

Although the notation is the same, the outcome is different, creating a new record instead of converting between equivelent representations.

I think the problem is that the newRelated function has two different outcomes, two different return values, record or collection.

newRelated is really a shortcut for

$model->getRelated('foos')->getModel()->newCollection();

or

$model->getRelated('foo')->getModel()->fetchNew();

So, making relationships always have collections would eliminate the need for the first form.

As far as the second form, I don't find it a problem at all to say fetchNew when you mean to create a new record.

I've stated before all my objections to empty record. I don't see anything in this proposal that changes that.

So, no different than my last opinion. :)

Jeff
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T12:58:34Z

> I started the background process like this:
> exec(PATH_TO_PHP . " script.php $param > /dev/null 2>&1 &");

> Mayhaps some of this will be useful to you, if not feel free to disregard
> :D

Hay yes thank you, exactly what I needed to see, your are a scholar &
gentleman :-)
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T12:40:32Z

I did something similar for a project where I was analyzing a lot of files(which I wanted to do in the background) and show an ajaxy progress meter. This background script would analyze the files and print a result to a log file, then from the parent script (which wasnt waiting for the child) it would just read a log file every so many seconds (ajax call) and update the meter and info it was displaying.

I started the background process like this:
exec(PATH_TO_PHP . " script.php $param > /dev/null 2>&1 &");

now in the script.php I needed to use solar to do some magic and run some logic I had in controllers, to do this I did something like this:

        $system = dirname(dirname(dirname(__FILE__))); // i house the script.php in my vendor/script folder
        set_include_path("$system/include");

        $solar_config = include "$system/config/Solar.config.php";
        require 'Solar.php';
        Solar::start($solar_config);

        $this->_model = Solar_Registry::get('model_catalog');
        session_id('batch_process');

        foreach ($this->files as $file) {
            $this->processFile($file);
        }

        Solar::stop();

-----
Mayhaps some of this will be useful to you, if not feel free to disregard :D

Anthony Gentile

On Mon, Nov 23, 2009 at 2:21 PM, Jon Elofson <jon.elofson@...> wrote:

Could you just create a separate bootstrap file that uses a separate
config file and call that from the command line?

$ php /path/to/index-test.php

Your config could specify the vendor and default app to run, cache params etc.

I haven't tested that but maybe it would work.

Jon

On 11/23/09, Jeff Surgeson <jeff@...> wrote:
>> > Are there any pointers anyone can give with regards running a
>> > background process, cron job etc, when using solar.
>> > Any pointers would be appreciated.
>>
>> My first thought is to extract the cache-building logic to its own
>> class. Your Solar_App would call that class to do the heavy lifting.
>> Then you can write a minimal Solar_Cli comman (or even a standalone
>> PHP script) to use that external cache-building class, and a cron job
>> can invoke the command or standalone script.
>>
>> Does that help?
>
> It does. food for thought at least, still not sure how to go about it, but
> will try a few things and then repost for comment.
>
> Thanks!
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk
>

--
Sent from my mobile device

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: Reviewing Remodel Branch

2009-11-23T12:38:14Z

On Nov 23, 2009, at 14:15 , Jeff Moore wrote:

> Thanks for your work in incorporating feedback, btw.

Dude, you are totally welcome. I know I don't have all the best
ideas. Gotta have you guys to keep me honest. :-)

--

Paul M. Jones
http://paul-m-jones.com/

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T12:37:13Z

> Could you just create a separate bootstrap file that uses a separate
> config file and call that from the command line?
>
> $ php /path/to/index-test.php
>
> Your config could specify the vendor and default app to run, cache params
> etc.
>
> I haven't tested that but maybe it would work.
>
> Jon

Sounds like what I am trying to do, trying to put together a single solar file
that sets up a solar env and allows me to run my vendor app, that I can
execute by running a cron job.
Never played with cli stuff other than make_vendor etc, so trying to hack out
something from Solar_Cli
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T12:21:16Z

Could you just create a separate bootstrap file that uses a separate
config file and call that from the command line?

$ php /path/to/index-test.php

Your config could specify the vendor and default app to run, cache params etc.

I haven't tested that but maybe it would work.

Jon

On 11/23/09, Jeff Surgeson <jeff@...> wrote:

>> > Are there any pointers anyone can give with regards running a
>> > background process, cron job etc, when using solar.
>> > Any pointers would be appreciated.
>>
>> My first thought is to extract the cache-building logic to its own
>> class. Your Solar_App would call that class to do the heavy lifting.
>> Then you can write a minimal Solar_Cli comman (or even a standalone
>> PHP script) to use that external cache-building class, and a cron job
>> can invoke the command or standalone script.
>>
>> Does that help?
>
> It does. food for thought at least, still not sure how to go about it, but
> will try a few things and then repost for comment.
>
> Thanks!
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk
>

--
Sent from my mobile device
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: Reviewing Remodel Branch

2009-11-23T12:15:24Z

Thanks for your work in incorporating feedback, btw.

Jeff
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: Reviewing Remodel Branch

2009-11-23T12:14:07Z

On Nov 23, 2009, at 8:48 AM, Paul M Jones wrote:

> On Oct 12, 2009, at 18:59 , Jeff Moore wrote:
>
>> Hi Paul,
>>
>> On Oct 10, 2009, at 9:23 AM, Paul M Jones wrote:
>>
>>> Good call, and I fully agree. To sum up:
>>>
>>> - The $where property of Solar_Sql_Model_Related is renamed to
>>> $join_cond
>>>
>>> - The relationship definition key for 'where' is also renamed to
>>> 'join_cond'
>>>
>>> - The 'join_cond' value in the relationship definition is always
>>> added
>>> to the JOIN conditions, not the WHERE conditions
>>>
>>> Does that sound right?
>>
>> Sounds perfect to me.
>
> Sounded perfect to me too. Turns out it was at least partially
> wrong. The relationship-definition conditions go in the JOIN clause
> sometimes, and in the WHERE clause sometimes. For example:
>
> - eager to-one: JOIN
> - eager has-many: WHERE (because we fetch the eager after the native)
> - eager has-many-through: the "through" conditions always go in the join
> - eager has-many join_flag: JOIN for the join, then WHERE for the fetch
> - lazy-load: WHERE
>
> Cf. the new work in branches/beta, including the tests (!!!) in
> Test_Solar_Sql_Related and the corresponding mock models in
> Mock_Solar_Model.
>
> So a simple "always and only use in the JOIN" isn't sufficient. I'm
> considering renaming from "where" to "conditions" (instead of to
> "join_cond") to hint toward that.

Yeah, that sounds good. There can't be a direct mapping of object to sql concepts and still provide consistency. There is already too much juggling of queries. Fragments must be placed at the right location to maintain consistency. If the fragment is over-specified (under-abstracted) in the relationship definition or query definition, then the internals cannot do the right thing.

On the other hand, if the query definition and relationship definition only allow very abstract concepts, there are queries you cannot do that you might want to do. As we've discussed, I think the way out of this conundrum is to break apart the query building stage from the result processing stage and use a mapping description passed from the first stage to the second. That way, each stage can evolve to support what is necessary.

I feel as long as they are coupled, there will be issues balancing back and forth between the need to represent a broad array of queries and the need to present a stable model for the purposes of writing domain logic on that model.

>> I don't think there is any reasonable need to support the LEFT JOIN
>> case in the relationship definition.
>
> It looks like LEFT JOIN has to be the default join type, to make sure
> that parent record sets are always the same regardless of eagers.
> Using "inner join" with "0=1" conditions, as noted in ticket 208 <https://solarphp.com/trac/core/ticket/208
>> , changes the native result set, which conflicts with the goal of
> keeping native result sets the same regardless of eagers. Let me know
> if I'm missing something here.

I think all i meant was that it wasn't necessary to have the option. Internally, the query builder can choose as appropriate for the situation.

> The only issue, then is supporting it on eager options. I think as
>> long as the modEagerFetch method gets added with both the fetch and
>> eager options parameters, then I don't see any need for where in the
>> eager options, only join_cond.
>
> That's another place where the conditions end up going in different
> places depending on the operation. If the "where" in the relationship
> definition gets renamed to "conditions", then it would make sense to
> call the eager key "conditions" as well.

ok.

These are just initial impressions without having run our standard set of problem queries and relationships. (soft-delete, area restriction, large datasets, etc.)

Jeff
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T09:30:29Z

> > Are there any pointers anyone can give with regards running a
> > background process, cron job etc, when using solar.
> > Any pointers would be appreciated.
>
> My first thought is to extract the cache-building logic to its own
> class. Your Solar_App would call that class to do the heavy lifting.
> Then you can write a minimal Solar_Cli comman (or even a standalone
> PHP script) to use that external cache-building class, and a cron job
> can invoke the command or standalone script.
>
> Does that help?

It does. food for thought at least, still not sure how to go about it, but
will try a few things and then repost for comment.

Thanks!
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: Pruning beta/nullrec and beta/unfounded

2009-11-23T09:17:53Z

On Nov 23, 2009, at 11:05 , Paul M Jones wrote:

> Hi all,
>
> I'm preparing to delete the beta/nullrec and beta/unfounded model-
> experimentation branches. I am not going to port their behaviors back
> to beta or trunk at this time, seeing as they met with mostly negative
> feedback. (The Collection::isEmpty() method might be an exception
> here, since everyone seemed to like that OK, but it would be that
> method itself, not the behavior in relation to fetching empty
> collections.)

The beta-nullrec branch is now gone, but it looks like there are some
other things in beta-unfounded that are useful, e.g.
Solar_Struct_Iterator. I'll take a closer look and report further
before I kill off beta-unfounded.

--

Paul M. Jones
http://paul-m-jones.com/

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Pruning beta/nullrec and beta/unfounded

2009-11-23T09:05:58Z

Hi all,

I'm preparing to delete the beta/nullrec and beta/unfounded model-
experimentation branches. I am not going to port their behaviors back
to beta or trunk at this time, seeing as they met with mostly negative
feedback. (The Collection::isEmpty() method might be an exception
here, since everyone seemed to like that OK, but it would be that
method itself, not the behavior in relation to fetching empty
collections.)

--

Paul M. Jones
http://paul-m-jones.com/

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: Reviewing Remodel Branch

2009-11-23T08:48:34Z

On Oct 12, 2009, at 18:59 , Jeff Moore wrote:

> Hi Paul,
>
> On Oct 10, 2009, at 9:23 AM, Paul M Jones wrote:
>
>> Good call, and I fully agree. To sum up:
>>
>> - The $where property of Solar_Sql_Model_Related is renamed to
>> $join_cond
>>
>> - The relationship definition key for 'where' is also renamed to
>> 'join_cond'
>>
>> - The 'join_cond' value in the relationship definition is always
>> added
>> to the JOIN conditions, not the WHERE conditions
>>
>> Does that sound right?
>
> Sounds perfect to me.

Sounded perfect to me too. Turns out it was at least partially
wrong. The relationship-definition conditions go in the JOIN clause
sometimes, and in the WHERE clause sometimes. For example:

- eager to-one: JOIN
- eager has-many: WHERE (because we fetch the eager after the native)
- eager has-many-through: the "through" conditions always go in the join
- eager has-many join_flag: JOIN for the join, then WHERE for the fetch
- lazy-load: WHERE

Cf. the new work in branches/beta, including the tests (!!!) in
Test_Solar_Sql_Related and the corresponding mock models in
Mock_Solar_Model.

So a simple "always and only use in the JOIN" isn't sufficient. I'm
considering renaming from "where" to "conditions" (instead of to
"join_cond") to hint toward that.

> I don't think there is any reasonable need to support the LEFT JOIN
> case in the relationship definition.

It looks like LEFT JOIN has to be the default join type, to make sure
that parent record sets are always the same regardless of eagers.
Using "inner join" with "0=1" conditions, as noted in ticket 208 <https://solarphp.com/trac/core/ticket/208
>, changes the native result set, which conflicts with the goal of
keeping native result sets the same regardless of eagers. Let me know
if I'm missing something here.

> The only issue, then is supporting it on eager options. I think as
> long as the modEagerFetch method gets added with both the fetch and
> eager options parameters, then I don't see any need for where in the
> eager options, only join_cond.

That's another place where the conditions end up going in different
places depending on the operation. If the "where" in the relationship
definition gets renamed to "conditions", then it would make sense to
call the eager key "conditions" as well.

--

Paul M. Jones
http://paul-m-jones.com/

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-23T07:48:25Z

On Nov 23, 2009, at 00:55 , Jeff Surgeson wrote:

> Hi All
>
> Are there any pointers anyone can give with regards running a
> background
> process, cron job etc, when using solar.
>
> Are there any do's or dont's, best way to handle etc.
>
> I have already written a Solar_App that fetches multiple rss remote
> files,
> saves to Solar_Cache, first checks cache files for timestamp/expiry
> etc before
> fetching, renames the files, and does other stuff to make it
> suitable for
> website use. I have the cache working so that these locally saved
> files are
> available to any website on my server. Unfortunately the website
> that ends up
> fetching these files when they expire, suffers as the process can
> take a while
> depending on remote server conditions etc.
>
> I thought it pointless to re-write a cli script to redo all of this,
> and was
> wondering best way to handle this?
>
> Any pointers would be appreciated.

My first thought is to extract the cache-building logic to its own
class. Your Solar_App would call that class to do the heavy lifting.
Then you can write a minimal Solar_Cli comman (or even a standalone
PHP script) to use that external cache-building class, and a cron job
can invoke the command or standalone script.

Does that help?

--

Paul M. Jones
http://paul-m-jones.com/

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: how to run a background process with solar

2009-11-22T23:11:47Z

Take a look at Solar_Cli a lot of helpers there with command line input and such, otherwise watch out for overlapping crons and memory leaks..

Richard Thomas
http://www.cyberlot.net

On Nov 22, 2009, at 10:55 PM, Jeff Surgeson wrote:

> Hi All
>
> Are there any pointers anyone can give with regards running a background
> process, cron job etc, when using solar.
>
> Are there any do's or dont's, best way to handle etc.
>
> I have already written a Solar_App that fetches multiple rss remote files,
> saves to Solar_Cache, first checks cache files for timestamp/expiry etc before
> fetching, renames the files, and does other stuff to make it suitable for
> website use. I have the cache working so that these locally saved files are
> available to any website on my server. Unfortunately the website that ends up
> fetching these files when they expire, suffers as the process can take a while
> depending on remote server conditions etc.
>
> I thought it pointless to re-write a cli script to redo all of this, and was
> wondering best way to handle this?
>
> Any pointers would be appreciated.
>
> Jeff Surgeson
> South Africa
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

how to run a background process with solar

2009-11-22T22:54:48Z

Hi All

Are there any pointers anyone can give with regards running a background
process, cron job etc, when using solar.

Are there any do's or dont's, best way to handle etc.

I have already written a Solar_App that fetches multiple rss remote files,
saves to Solar_Cache, first checks cache files for timestamp/expiry etc before
fetching, renames the files, and does other stuff to make it suitable for
website use. I have the cache working so that these locally saved files are
available to any website on my server. Unfortunately the website that ends up
fetching these files when they expire, suffers as the process can take a while
depending on remote server conditions etc.

I thought it pointless to re-write a cli script to redo all of this, and was
wondering best way to handle this?

Any pointers would be appreciated.

Jeff Surgeson
South Africa
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T13:33:20Z

I thought that was ON the coconut trees, I still hold that being 'in' the
tree is difficult on a tree that has no branches. Of course when I think
Africa I think Algeria or Timbuktu. Didn't see too many coconut trees when I
was in Algeria or from the pictures of my grandfather/brothers trip out to
Timbuktu.

James Kilbride

-----Original Message-----
From: Jeff Surgeson [mailto:jeff@...]
Sent: Thursday, November 19, 2009 1:27 PM
To: solar-talk@...
Cc: Kilbride, James P.
Subject: Re: [Solar-talk] CamelCased Models (with latestsvn) does not work

> How exactly does one get 'in' a coconut tree in order to throw yourself
out
> of one?

"TIA"

This is Africa, we spend most of our time in coconut trees, don't you watch
National Geographic?

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

smime.p7s (3K) Download Attachment

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T10:27:06Z

> How exactly does one get 'in' a coconut tree in order to throw yourself out
> of one?

"TIA"

This is Africa, we spend most of our time in coconut trees, don't you watch
National Geographic?
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T10:22:45Z

> Ok here's my result
> Create the model app with --model-name=gallery_cat
> Everything seems ok to me.
> Paul's tip about --model-name=gallery_cat should help.
> Jon

Jon thanks for taking the time to do that, even it was just to confirm I am in
fact nuts.

Paul sorry for casting doubt, should know different by now after 5 years or
more of using your code.

Jeff
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T09:41:38Z

How exactly does one get 'in' a coconut tree in order to throw yourself out
of one?

-----Original Message-----
From: solar-talk-bounces@...
[mailto:solar-talk-bounces@...] On Behalf Of Jeff Surgeson
Sent: Thursday, November 19, 2009 10:56 AM
To: Paul M Jones
Cc: solar-talk@...
Subject: Re: [Solar-talk] CamelCased Models (with latestsvn) does not work

> > ./script/solar make-app Yak_App_GalleryCat --model-name=GalleryCat
>
> Try `--model-name=gallery_cat`. Studly caps ("FooBar") in classes are
> translated to lower-case-underscores ("foo_bar") in model names.

Quick try, seems to do the trick, will apply to a complete app, but I am
sure
it will be fine.

The only change it made was to set up $this->model_name = 'gallery_cat';

So I am nuts :( I cant believe after playing for 2 days I did not try that,
well I am off to throw myself out of a coconut tree.

Paul drop for 50 - :D
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

smime.p7s (3K) Download Attachment

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T08:13:35Z

Ok here's my result

Svn checkout of solar system which includes core as svn external

Set up apache to find it using an alias
Edit .htaccess a bit
Create the gallery cat table in mysql
Create the yak vendor
Create Yak_Model_GalleryCat (get error about table_cols so run again. No error)

Create the model app with --model-name=gallery_cat

Edit Solar.config.php to use mysql and set the model catalog and
controller front to use Yak

Browse to gallery-cat and add a record. Works.
Edit works
Delete works

Everything seems ok to me.
Paul's tip about --model-name=gallery_cat should help.

Jon

On 11/19/09, Paul M Jones <pmjones@...> wrote:

>
> On Nov 19, 2009, at 04:48 , Jeff Surgeson wrote:
>
>> ./script/solar make-app Yak_App_GalleryCat --model-name=GalleryCat
>
> Try `--model-name=gallery_cat`. Studly caps ("FooBar") in classes are
> translated to lower-case-underscores ("foo_bar") in model names.
>
>
>
> Paul M. Jones
> http://paul-m-jones.com/
>
>
>
>
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk
>

--
Sent from my mobile device
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T07:55:35Z

> > ./script/solar make-app Yak_App_GalleryCat --model-name=GalleryCat
>
> Try `--model-name=gallery_cat`. Studly caps ("FooBar") in classes are
> translated to lower-case-underscores ("foo_bar") in model names.

Quick try, seems to do the trick, will apply to a complete app, but I am sure
it will be fine.

The only change it made was to set up $this->model_name = 'gallery_cat';

So I am nuts :( I cant believe after playing for 2 days I did not try that,
well I am off to throw myself out of a coconut tree.

Paul drop for 50 - :D
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T07:27:29Z

On Nov 19, 2009, at 04:48 , Jeff Surgeson wrote:

> ./script/solar make-app Yak_App_GalleryCat --model-name=GalleryCat

Try `--model-name=gallery_cat`. Studly caps ("FooBar") in classes are
translated to lower-case-underscores ("foo_bar") in model names.

Paul M. Jones
http://paul-m-jones.com/

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T06:44:29Z

> I Jeff,
> I do have camel cased apps and models, but I pulled my source from the
> alpha5 download. I also used the command line scripts to generate all my
> classes; nothing hand coded. When I get to work I will try to pull the
> latest system from svn and see if I can confirm your bug.
>
> I am sure you're not nuts - at least not in a bad way. :)

Cheers Jon, was starting to develop a complex :( will also try it with a alpha
source and see if it makes any difference.

Let me know what you find

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

Re: CamelCased Models (with latestsvn) does not work

2009-11-19T06:12:30Z

I Jeff,
I do have camel cased apps and models, but I pulled my source from the
alpha5 download. I also used the command line scripts to generate all my
classes; nothing hand coded. When I get to work I will try to pull the
latest system from svn and see if I can confirm your bug.

I am sure you're not nuts - at least not in a bad way. :)

Jon

On Thu, 2009-11-19 at 12:48 +0200, Jeff Surgeson wrote:

> Sorry to start this anew, but to clear things up and make sure that I am not
> mad I thought I would start from scratch and lay out what I have done to show
> you that it does NOT work. To eliminate any user errors I downloaded latest
> svn trunk for core & system, used the cli commands to create vendor/app/model
> without any changes or overrides to any solar code other than solar_config for
> db connection stuff
>
> # Download latest core & system trunk (19 Nov)
> http://svn.solarphp.com/core/trunk
> http://svn.solarphp.com/system/trunk
>
> # Create a simple mysql table
> CREATE TABLE IF NOT EXISTS `gallery_cat` (
> `id` int(11) NOT NULL auto_increment,
> `title` varchar(255) collate utf8_bin NOT NULL,
> PRIMARY KEY (`id`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1 ;
>
> # Run Solar cli commands to create vendor, app & model
> ./script/solar make-vendor Yak
> ./script/solar make-model Yak_Model_GalleryCat
> ./script/solar make-app Yak_App_GalleryCat --model-name=GalleryCat
>
> # Browse to app
> http://localhost/xsolar_system/docroot/gallery-cat
>
> If any records exist in gallery_cat table, it will display them on browse, if
> you try add a record or edit an existing record the save/update FAILS!
>
> Just to further verify this I created a new model & app the same way except no
> CamelCase, like so:
>
> ./script/solar make-app Yak_App_Gallerycat --model-name=gallerycat
> ./script/solar make-model Yak_Model_Gallerycat
>
> save/update etc work fine, So please someone confirm that I am not nuts :D
>
> Jon I know you said that you have many CamelCased models that work fine, I can
> only say that you probably hand coded all aspects and must be doing something
> different.
>
> I can also assume from this that most do not use CamelCased apps and models or
> you would have come across this as well. So it begs the question is CamelCased
> Models and App's something to avoid? I respect what you guys say, if the
> opinion is yes, it is to be avoided, then please say. That way I can drop this
> quest and get on with my life. :D
>
> Jeff Surgeson
> (not nuts or ape, from darkest africa)
> _______________________________________________
> Solar-talk mailing list
> Solar-talk@...
> http://mailman-mail5.webfaction.com/listinfo/solar-talk

_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk

CamelCased Models (with latestsvn) does not work

2009-11-19T02:48:11Z

Sorry to start this anew, but to clear things up and make sure that I am not
mad I thought I would start from scratch and lay out what I have done to show
you that it does NOT work. To eliminate any user errors I downloaded latest
svn trunk for core & system, used the cli commands to create vendor/app/model
without any changes or overrides to any solar code other than solar_config for
db connection stuff

# Download latest core & system trunk (19 Nov)
http://svn.solarphp.com/core/trunk
http://svn.solarphp.com/system/trunk

# Create a simple mysql table
CREATE TABLE IF NOT EXISTS `gallery_cat` (
`id` int(11) NOT NULL auto_increment,
`title` varchar(255) collate utf8_bin NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1 ;

# Run Solar cli commands to create vendor, app & model
./script/solar make-vendor Yak
./script/solar make-model Yak_Model_GalleryCat
./script/solar make-app Yak_App_GalleryCat --model-name=GalleryCat

# Browse to app
http://localhost/xsolar_system/docroot/gallery-cat

If any records exist in gallery_cat table, it will display them on browse, if
you try add a record or edit an existing record the save/update FAILS!

Just to further verify this I created a new model & app the same way except no
CamelCase, like so:

./script/solar make-app Yak_App_Gallerycat --model-name=gallerycat
./script/solar make-model Yak_Model_Gallerycat

save/update etc work fine, So please someone confirm that I am not nuts :D

Jon I know you said that you have many CamelCased models that work fine, I can
only say that you probably hand coded all aspects and must be doing something
different.

I can also assume from this that most do not use CamelCased apps and models or
you would have come across this as well. So it begs the question is CamelCased
Models and App's something to avoid? I respect what you guys say, if the
opinion is yes, it is to be avoided, then please say. That way I can drop this
quest and get on with my life. :D

Jeff Surgeson
(not nuts or ape, from darkest africa)
_______________________________________________
Solar-talk mailing list
Solar-talk@...
http://mailman-mail5.webfaction.com/listinfo/solar-talk