Hi! Looks like we need to do something with this issue. 1. Make sitegroup settable with property value set, with condition that it is only safe when object was just created and has not attachments and parameters? Or 2. Implement setsitegroup method which sets all related objects' sitegroup including object itself? Piotras
Hi! Current CVS HEAD is becoming installable only nicer. It means that we can prepare for 1.8alpha2 release soon. However we still have few issues. * Sitegroup part of midgard-core should be reviewed * midgard_sitegroup class should be implemented as internal one * midgard_reflection_class must be implemented * midgard_reflection_property should be debugged to check if PHP's resources handler is not leaking "Broken" backward compatibility: * list_childs and list methods These two methods returns full list of child objects now. ( I will update documentation soon ) * dot and colon separator used in QB's constraints We didn't make any clear decision yet. Midgard-php * metadata properties Frankly speaking I count on Torben's help in this matter as we do not want to support '_' in properties' names, and those midcom related contain underscores. 1.8 release is going to be much better 1.7 with improved performance and many bugs being fixed. There are no huge higher level changes in API so we should(Continue reading)
Hi,
First. Tarjei, great thanks for discovering this issue!
We have serious sitegroup issue, and again it's somehow caused by midgard
logic ( legacy core ) shared between midgard-core and midgard-php.
What happens when you want to update object's sitegroup and you set sitegroup
property with some value and call update method? Internal UPDATE_REPLIGARD
macro is used then, after object's record was successfully updated.
But the problem is that this macro is not sitegroup aware!
command = mgd_format(mgd, mgd->tmp,
"UPDATE $s SET locked=1,author=$d,$s WHERE id=$d AND realm=$q",
"repligard", mgd->current_user->id, fields, id, table);
It's easy to notice that after calling update method , object's record has sitegroup value updated
while repligard entry has still old value , so in practice this object doesn't exist.
Interesting thing is that old setsitegroup method updates sitegroup value.
php_midgard_update(return_value,
(*zv_table)->value.str.val,
"sitegroup=$d", (*zv_id)->value.lval,
(*zv_sitegroup)->value.lval);
mgd_update_repligard(mgd_handle(), (*zv_table)->value.str.val, (*zv_id)->value.lval,
"sitegroup=$d", (*zv_sitegroup)->value.lval);
I will review all sitegroup's related code in HEAD and in 1-7 branch tomorrow.
(Continue reading)
Hi, is mgd_get_midgard depreciated? I was trying to use it to check if commandline authentication is working in 1.7.4 but it only returned false. Is this correct behaviour? Tarjei -- -- Tarjei Huse <tarjei@...>
Hi, mRFC states that the version of the host configuration should be stored as a parameter to the page. I suggest that we also add the other configuration options as parameters to the same page with the same domain - "midgard". This will make configuration editing easier. Any comments? Tarjei -- -- Tarjei Huse <tarjei@...>
Hi, Changing the subject to a bit more descriptive one.(Continue reading)On 3/6/06, Piotras <pp <at> infoglob.com> wrote: > I would like to propose a simple convention. > What's GObject in core is designed for language binding, while what isn't GObject > should be used only in core. I wouldn't be that strict. Use what best suits the requirements. Using GObjects is no magic dust to make language bindings easy, GObjects just provide a standard set of features (properties, signals, data attachments, inheritance, introspection, etc.) that is well supported in a variety of environments. Using GObjects for stuff that doesn't need those features (for example MidgardConnection doesn't really need generic properties or introspection, but signals and data attachments might be nice) is just extra work. > > a) use g_log_set_default_handler() to handle log messages from > > *all* log domains, or > > Yeah, but this is GLib 2.6 :/ You're already using it in src/config.c. In any case we shouldn't be using either of the g_log_set functions in midgard-core. If an application wants to use g_log_set_default_handler(), it should require GLib 2.6. > OK, help me with real issue now. > While you use repligard in HEAD you use "repligard" G_LOG_DOMAIN , while core
I have some problems building packages for ubuntu breezy. Seems like it pukes on some includes. Anyone that has an idea on how to solve it ? /Johan -c src/mgdschema.c -fPIC -DPIC -o .libs/src_libmidgard_la-mgdschema.o In file included from src/mgdschema.c:23: /usr/include/libxml2/libxml/parser.h:1196: error: redeclaration of enumerator 'XML_FEATURE_UNICODE' /usr/include/expat.h:971: error: previous definition of 'XML_FEATURE_UNICODE' was here src/mgdschema.c: In function '_get_element_names': src/mgdschema.c:251: warning: pointer targets in passing argument 2 of 'xmlGetProp' differ in signedness src/mgdschema.c:279: warning: pointer targets in passing argument 2 of 'xmlGetProp' differ in signedness src/mgdschema.c:280: warning: pointer targets in passing argument 2 of 'midgard_schema_lookup_type_member' differ in signedness src/mgdschema.c:280: warning: pointer targets in passing argument 3 of 'midgard_schema_lookup_type_member' differ in signedness src/mgdschema.c:302: warning: pointer targets in passing argument 1 of 'g_ascii_strcasecmp' differ in signedness make[1]: *** [src_libmidgard_la-mgdschema.lo] Error 1 make[1]: Leaving directory `/home/jobe/new/Midgard_AllinOne-1.7.4/midgard-core-1.7.4' make: *** [build-stamp] Error 2 -- --(Continue reading)
On Mar 3, 2006, at 12:56, tarjei@... wrote: > Change of strategy for adding nodes outside the menu_path. Now > they are added without an extra call to create_menu_nodes. I'd propose a bit more refactoring to use the Prototype JS library... http://wiki.script.aculo.us/scriptaculous/show/Prototype /Henri Henri Bergius Consultant Partner, Nemein henri.bergius@... Midgard CMS www.midgard-project.org
Hi, while debugging It dawned to me that when I create an object using the new api, the object's guid will not be set. I'm wondering: a) Is this a bug or a feature? b) Is it simple to fix? c) Are there technical reasons why the objects guid cannot be updated when the id is? Tarjei -- -- Tarjei Huse <tarjei@...>
Hi, for all of you who are using the latest Midgard tech on productive servers: Be aware that some part of the package produces duplicate entries in the repligard table. Midgard Core DOES NOT handle this case correctly. Versions before something around 1.7.3 do just ignore the case leading to the actual duplicates (which breaks MidCOM owner privileges and other stuff done directly after create()), while newer versions prevent object creation in such a case (detected by an UNIQUE INDEX, this is almost as bad as it prevents object creation for obscure reasons to users). I am encountering this problem on a regular basis on at least one live site, but have not yet found a way to reproduce. I thus recommend against using this piece of software until this situation is resolved. Specifically I officially remove any recommendation to deploy and MidCOM 2.5 on live sites until this is resolved. I cannot support any of these combinations until either the root of this problem is solved or at least the core gets more error-resilent in this matter. This includes any bug reporting where either MidCOM 2.5 or Midgard 1.7 is concerned. Such bugs will not be rejected if any hint is there that points me to the conclusion that the mentioned bug may be the root of this problem. Details can be found at the Midgard Bug Report #118 [1] which also contains a script [2] usable to detect and remove these duplicates in case you absolutely(Continue reading)
Hi, --rambo@... wrote on 2006-03-02 13:07: > +2006-03-02 rambo > + + added request_sudo and drop_sudo around all object operations in check.php > + (in case the sudo requested by cron gets dropped during the execution of the job) Rather find the bug where the sudo gets dropped... Would be more helpfulHint: use debug_print_function_stack in drop_sudo to locate. Live long and Prosper! Torben Nehmer -- Torben Nehmer, Guenzburg, Bavaria, Germany http://www.nathan-syntronics.de, mailto:torben@... PGP Public Key: https://www.link-m.de/pgp/t.nehmer.asc
 |
|
|
|
|
|
|
| Mon | Tue | Wed | Thu | Fri | Sat | Sun |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | ||
| 6 | 7 | 8 | 9 | 10 | 11 | 12 |
| 13 | 14 | 15 | 16 | 17 | 18 | 19 |
| 20 | 21 | 22 | 23 | 24 | 25 | 26 |
| 27 | 28 | 29 | 30 | 31 |
RSS Feed131 | |
|---|---|
269 | |
108 | |
240 | |
116 | |
103 | |
93 | |
179 | |
126 | |
34 | |
123 | |
77 | |
96 | |
42 | |
73 | |
72 | |
71 | |
64 | |
80 | |
38 | |
84 | |
24 | |
118 | |
158 | |
306 | |
96 | |
94 | |
152 | |
301 | |
115 | |
227 | |
126 | |
188 | |
258 | |
216 | |
369 | |
193 | |
140 | |
219 | |
232 | |
228 | |
202 | |
343 | |
288 | |
36 | |
1 |